ごだっくのぽんぽこ珍道中

日々のネタやロードバイクの旅ログ的な、他人様の役に立たない日記を書いてます

AIにコードを書かせていたら、うっかりmacOSアプリを作っていた話

久しぶりにこのブログも書く。
ネタも久しぶりにエンジニアとしての内容。

といっても、エンジニアとしてというより、最近流行りのAIコーディングについての、オジサンの感想文です。

ここ1〜2年くらいで、AIにコードを書かせる環境が一気に現実のものになってきた。

ChatGPT、Claude、Claude Code、Cursor、GitHub Copilot、Gemini CLI、その他いろいろ。
名前を挙げだすとキリがないのだけど、とにかく「こういうものを作りたい」と伝えると、それっぽいコードが出てくる。しかも、昔の「サンプルコードをちょっと出してくれる」みたいなレベルではなく、かなりの量を一気に書いてくる。

正直、これはかなりすごい。

すごいのだけど、同時にちょっと怖いなとも思っている。

自分がスーパーエンジニアになったと勘違いするだろう問題

AIコーディングを使っていると、けっこうなものが作れてしまう。

画面が出る。
ボタンが動く。
DBにつながる。
認証も入る。
GitHub Actionsも動く。
デプロイもできる。

なんなら、自分がよく分かっていないエラーメッセージもAIに投げると、
「ああ、それはこの設定が足りませんね」
みたいな顔をして修正案を出してくる。

すごい時代になったもんだよ。

ただ、ここで若い人が、

「もしかして自分、めちゃくちゃ開発できるのでは?」

と思ってしまうと、それはちょっと危うい気がしている。

いや、実際に開発できているのだから、ある意味では間違っていない。
昔なら数年かけて覚えていたようなことを、AIの補助付きで短期間に体験できるのは間違いなく強い。

でも、それがそのまま「自分の実力」かというと、そこは少し違う。

AIが出してきたコードがなぜ動いているのか。
どこが危ないのか。
どこが雑なのか。
この設計で半年後に自分が泣くのか。
ユーザーが増えたらどこから壊れるのか。
秘密情報が漏れないか。
ライセンス的に大丈夫なのか。
そのライブラリ、3年後も生きているのか。

そういう、地味で面倒で、しかも後から効いてくる部分は、まだ人間側がかなり見ないといけない。(それすらも解決される世の中に進んでいきそうだけど)

AIは若くて頭の柔らかい、物知りで手の速いエンジニアみたいなものだと思っている。
ただし、ちょっと自信満々に間違える。
そして、こちらが何を分かっていないかまでは、あまり気にしてくれない。

そこが怖い。

本当にすごい人ほど、たぶん慎重になっている

一方で、本当にスーパーなエンジニアの人たち。
たとえば大きなテック企業でCTOをやっているような人たちは、もう単純な懐疑フェーズは抜けていると思う。

「AIなんて使えないでしょ」
みたいな段階では、もうないはず。

使える。かなり使える。
部分的には人間より速い。
しかも、これからさらに良くなる。

そこまでは、たぶん多くの人が認めている。

ただ、その次が難しい。

業務にどう組み込むのか。

個人が趣味でアプリを作るのと、会社の開発プロセスに正式に組み込むのとでは、話がだいぶ違う。

レビューはどうするのか。
AIが書いたコードの責任は誰が持つのか。
設計方針はどこまでAIに任せるのか。
セキュリティチェックはどうするのか。
社内のコードや仕様をどこまでAIに渡していいのか。
新人教育はどう変えるのか。
既存の開発チームの生産性は本当に上がるのか。
むしろレビュー負荷だけ増えないか。

これはかなり真面目な悩みだと思う。

AIコーディングは、単に「便利なエディタ拡張が増えました」という話ではない。
たぶん開発のやり方そのものが変わる。

ただ、変わるからといって、雑に突っ込めば良いというものでもない。

AIに任せるべきところ。
人間が見るべきところ。
人間が最初に考えなければいけないところ。
むしろAIに触らせない方がいいところ。

この境界線を、みんな手探りで探している段階なのだと思う。

で、お前はどうなんだという話

では自分はどうなのか。

私はもういい歳なので、さすがにこれで自分がスーパーエンジニアになったとは思っていない。そんなに素直な年齢ではない。

そもそも現場の第一線でコードを書き続けていたわけでもないし、ブランクも長い。
なので、AIがすごい勢いでコードを書いてくれると、ありがたい反面、内心ではずっとビビっている。

「これ、本当に大丈夫なんだろうか」
「この実装、あとで破綻しないだろうか」
「いま動いているだけじゃないのか」
「なんか妙に自信満々だけど、嘘ついてないか」

そんなことを思いながら使っている。

ただ、それでも作れてしまう。
これがまた面白い。

最近作ったのが、TameoというmacOS用のクリップボードマネージャである。公開名として Tameo にした。「ためお」。コピーしたものを溜めておくから、ためお。ネーミングが雑なのはいつものことです。

Tameoとは何か

Tameoは、macOS用のクリップボードマネージャです。

コピーしたテキストや画像、URL、ファイルパスなどを履歴として保存しておき、あとからホットキーで呼び出して貼り付けられるアプリ。

要するに、Clipyのようなものです。

というか、Clipyがとても好きで長年使っていたのだけど、Apple Silicon時代になり、Rosetta 2への依存が少しずつ気になるようになってきた。
いつか動かなくなるかもしれない。
それは困る。

じゃあ、Apple Siliconネイティブで、今のmacOSに合わせて、ローカル完結で、余計なことをしないクリップボードマネージャを作ればいいのでは。

という発想です。

……と言うと格好いいが、実際には、

「Clipyが将来使えなくなったら困るなあ」
「誰か作ってないかなあ」
「うーん、じゃあ作ってみるか」

くらいの感じである。

AIと一緒にmacOSアプリを作る

macOSアプリ開発は、自分にとって得意分野ではない。

SwiftもSwiftUIも、ちゃんとやってきたわけではない。
昔ながらのWeb系、業務系、あとなんやかんやの知識はあるけれど、macOSネイティブアプリをバリバリ書けます、というタイプではない。

それでも、AIに相談しながら進めると、かなり形になる。

SwiftUIでメニューバー常駐。
Dockアイコンなし。
グローバルホットキー。
クリップボード履歴。
スニペット。
画像やPDFやURLの扱い。
設定画面。
署名。
公証。
GitHub公開。
Webサイト作成。

一つ一つは面倒くさい。
でもAIに壁打ちしながら進めると、分からない部分を調べながら、試しながら、かなり前に進める。

もちろん、AIが全部やってくれるわけではない。

macOSの権限まわり、Pasteboardの扱い、アクセシビリティ権限、署名・公証、JIS配列やかな入力への対応などは、やってみると普通に沼がある。

AIもたまに、存在しないAPIを平気な顔で提案してくる。
「それはできません」とコンパイラに怒られる。
こちらが「できないじゃないか」と言うと、
「おっしゃる通りです」
などと急に素直になる。

このへんのやり取りは、もはや日常である。

AIコーディングで大事なのは、たぶん調子に乗らないこと

AIコーディングで一番大事なのは、たぶん調子に乗らないことだと思う。

AIがコードを書いてくれる。
動く。
それっぽい。
画面もきれい。
READMEも書いてくれる。
英語版も作ってくれる。
リリースノートも作ってくれる。

すると、なんとなく自分が何でもできるような気がしてくる。

でも、そこは一度冷静になった方がいい。

AIは強力な道具だけど、責任は取ってくれない。
ユーザーから問い合わせが来るのは自分。
不具合を直すのも自分。
変なデータを保存してしまったら困るのも自分。
セキュリティ事故が起きたら青ざめるのも自分。
夜中に「あれ、あの実装まずくないか」と思い出して眠れなくなるのも自分。

AIは横でめちゃくちゃ手伝ってくれるが、最後にハンコを押すのは人間である。

ここを忘れると危ない。

でも、やっぱり面白い

とはいえ、やっぱり面白い。

自分の中に、
「こういうものが欲しい」
という小さな不満やアイデアがある。

昔なら、そこで終わっていた。

時間がない。
技術的に面倒。
調べることが多い。
環境構築で萎える。
Apple Developerまわりで萎える。
まあ誰かが作ってくれるだろう。
そんな感じで放置していたものがたくさんある。

でも今は、AIに相談しながら少しずつ形にできる。

これはかなり大きい。

Tameoも、別に世界を変えるようなアプリではない。
クリップボードマネージャである。
地味である。
しかし毎日使う。
自分が困っていたものを、自分で作って、自分で使える。

これが楽しい。

しかもGitHubで公開している。
誰かが使ってくれるかもしれない。
使わないかもしれない。
スターが1つ増えただけでちょっとうれしい。
オジサンの趣味としては十分である。

業務としてのAIコーディング、趣味としてのAIコーディング

業務としてAIコーディングを使うなら、ちゃんとルールが必要だと思う。

AIに何をさせるのか。
何をさせないのか。
レビューをどうするのか。
設計書や仕様書をどう扱うのか。
テストをどう書かせるのか。
AIが書いたコードをどう検証するのか。

ここを決めないまま、
「AIで爆速開発!」
みたいにやると、後でしんどいことになる気がする。

一方で、個人の趣味や小さなツール作りでは、もっと気軽でいい。

作る。
壊す。
直す。
また作る。
GitHubに置く。
誰かに見せる。
自分で使う。

このサイクルが、ものすごく速くなった。

これは良いことだと思う。

昔、ホームページビルダーで個人サイトを作ったり、CGIを設置したり、JavaScriptをコピペして動かしたりしていた時代のワクワク感に近い。
分かる人には分かると思う。
アクセスカウンターとか、キリ番とか、掲示板とか、そういうやつです。

今はそれが、AIとGitHubとNetlifyと各種クラウドとmacOSアプリ開発環境になっている。

だいぶ遠くまで来たもんだよ。

まとめ

AIコーディングは、本当にすごい。
たぶんもう戻れない。

ただし、AIが書いてくれるからといって、自分が急にスーパーエンジニアになったわけではない。
そこは勘違いしない方がいい。

若い人ほど、AIを使い倒した方がいい。
でも同時に、AIが何をしているのか、なぜ動くのか、どこが危ないのかをちゃんと見る力も育てた方がいい。

本当にすごい人たちは、きっとそこを真剣に考えている。
単に使うか使わないかではなく、どう組み込むか。
どう責任を持つか。
どうチームの力にするか。

私はというと、そこまで大きな話をしつつも、実際にはAIに手伝ってもらいながら、クリップボードマネージャを作って喜んでいる。

Tameo。
ためお。
コピーしたものを溜めるやつです。

興味のある方は試してみてくださいませ。

Tameo
https://tameo.ati-mirai.co.jp/

GitHub
https://github.com/supergodak/tameo/

Parallels上のWindowsでIME切り替えを爆速にする設定メモ

Parallels上のWindows(US配列設定)において、Macの左右コマンドキー単押しで「英数・かな」をラグなし・誤爆なしで切り替えるための設定です。 Mac側(Karabiner-Elements)で単押しを判定し、Windows側(AutoHotkey v2)でIMEの状態を直接書き換えます。

  1. Mac側:Karabiner-Elementsの設定 karabiner.json の rules セクション内に以下の内容を追記してください。 左Command単押しで Ctrl + Alt + 8、右Command単押しで Ctrl + Alt + 9 を送信します。

{
    "description": "Parallels専用:左CmdでCtrl+Alt+8、右CmdでCtrl+Alt+9を送信",
    "manipulators": [
        {
            "conditions": [{ "bundle_identifiers": ["^com\\.parallels\\.desktop\\.console$", "^com\\.parallels\\.winapp$"], "type": "frontmost_application_if" }],
            "from": { "key_code": "left_command", "modifiers": { "optional": ["any"] } },
            "to": [{ "key_code": "left_command", "lazy": true }],
            "to_if_alone": [{ "key_code": "8", "modifiers": ["left_control", "left_alt"] }],
            "type": "basic"
        },
        {
            "conditions": [{ "bundle_identifiers": ["^com\\.parallels\\.desktop\\.console$", "^com\\.parallels\\.winapp$"], "type": "frontmost_application_if" }],
            "from": { "key_code": "right_command", "modifiers": { "optional": ["any"] } },
            "to": [{ "key_code": "right_command", "lazy": true }],
            "to_if_alone": [{ "key_code": "9", "modifiers": ["left_control", "left_alt"] }],
            "type": "basic"
        }
    ]
}

  1. Windows側:AutoHotkey v2のスプリクト 以下の内容を .ahk ファイルとして保存し、Windowsのスタートアップに登録します。

#Requires AutoHotkey v2.0
#SingleInstance Force
ListLines 0
ProcessSetPriority "High"

; IME状態を直接セットする関数
SetIME(mode) {
    try {
        hWnd := WinGetID("A")
        DefaultIMEWnd := DllCall("imm32\ImmGetDefaultIMEWnd", "Ptr", hWnd, "Ptr")
        ; 0x0283: WM_IME_CONTROL, 0x006: IMC_SETOPENSTATUS
        DllCall("SendMessage", "Ptr", DefaultIMEWnd, "UInt", 0x0283, "UPtr", 0x006, "Ptr", mode)
    }
}

; Karabinerから送られてくる Ctrl+Alt+8/9 に反応
^!8::SetIME(0) ; 英語(OFF)へ
^!9::SetIME(1) ; 日本語(ON)へ

  1. 事前に必要な設定

動作を安定させるために、以下の項目を設定してください。

  • Windows IMEの設定
    • 設定 > 時刻と言語 > 言語と地域 > 日本語 > 言語のオプション > Microsoft IME 「キーとタッチのカスタマイズ」を開き、Altキー空打ちなどの機能をすべてオフにする
  • Parallelsの設定
    • 設定 > オプション > 入力 > 「入力言語をMacと同期する」をオフにする
    • 設定 > ハードウェア > マウスとキーボード > ショートカット > Windows リストにあるCommandキー単体に関連する設定をすべて削除する

この設定により、US配列設定のWindowsでもキーの衝突を避け、左右独立したIME切り替えを爆速で行えるようになります。

PWAで作る「投げメモ」アプリ - 思いついたらすぐ送信、そしたら忘れてOK。

最近、メモを取るのが面倒である。最近というかもともとずっと。スマホのメモアプリを開いて、文字を入力して、保存して...という事すらも面倒で、そんなことをしているうちに、せっかくのアイデアを忘れてしまうことが多々ある。

 

  思いついたらすぐに送信して、あとは忘れてしまいたい

 

そんな発想から生まれたのが「投げメモ」というPWAアプリだ。今回はその技術スタックと設計思想について書いてみたい。

 

投げメモとは何か

投げメモは、その名の通り「メモを投げる」アプリだ。テキストを入力してボタンを押すと、指定したメールアドレスやSlackチャンネルに送信される。送信後はメモ内容が即座に削除され、履歴は一切残らない。

 

  「履歴が残らない」というのがポイントで、これはプライバシー重視の設計だ。思考の断片や恥ずかしいアイデアも気軽に投げることができる。そして色んな人に使ってもらうにあたり眠れなくなるようなやばいリスクも減らせる。

 

なぜPWAを選んだのか

PWA(Progressive Web App)を選んだ理由は単純だ。「ホーム画面からワンタップで起動したい」「オフラインでも使いたい」「アプリストアの審査を待ちたくない」という要求を満たすには、PWA一択ということ。

 

特に、思いついたアイデアをすぐに投げたいという用途では、起動の速さが命だ。PWAならブラウザキャッシュでほぼ瞬時に立ち上がる。

 

技術スタック

フロントエンド

  - React: お馴染みのライブラリ。コンポーネント設計がしやすい

  - Tailwind CSS: ユーティリティファーストで開発が早い

  - Service Worker: オフライン対応とキャッシュ戦略

 

バックエンド(というかAPI)

  - Netlify Functions: サーバーレスで運用コストゼロ

  - EmailJS: ブラウザから直接メール送信

  - Slack Webhook: プロキシ経由でCORS問題を回避

 

データ保存

  - localStorage: メールアドレスや設定情報

  - IndexedDB: オフライン時のメモキュー

  - サーバーには何も保存しない: プライバシー重視

 

面白い技術要素

日本語自然言語処理

「明日14時に会議」「来週金曜日にタスク」といった日本語を解析して、自動でカレンダーイベントを生成する機能を実装した。

 

  import chrono from 'chrono-node';

  const parseDateFromText = (text) => {

    // 日本語パターンのカスタム解析

    const patterns = [

      /明日(\d{1,2})時/,

      /来週(月|火|水|木|金|土|日)/,

      // ...その他のパターン

    ];

 

    // chrono-nodeとカスタムパターンを組み合わせ

    return parseWithBothMethods(text);

  };

 

意外と精度が高く、普段使いに十分な品質になった。

 

認証済みメール履歴管理

一度認証したメールアドレスは履歴に保存され、次回以降は認証をスキップできる。ただし、30日間使われなかった履歴は自動で削除される。

この機能により、複数のメールアドレス間での切り替えがストレスフリーになった。

 

Slack連携のCORS問題解決

Slack APIへの直接アクセスはCORSエラーで弾かれるため、Netlify Functionsでプロキシを作成した。

 

  // netlify/functions/send-to-slack.js

  exports.handler = async (event, context) => {

    const { webhookUrl, message } = JSON.parse(event.body);

 

    const response = await fetch(webhookUrl, {

      method: 'POST',

      headers: { 'Content-Type': 'application/json' },

      body: JSON.stringify(message)

    });

 

    return {

      statusCode: 200,

      headers: { 'Access-Control-Allow-Origin': '*' },

      body: JSON.stringify({ success: true })

    };

  };

 

シンプルだが効果的な解決策だ(と思っている)。

 

プライバシーファーストの設計

投げメモの最大の特徴は、徹底したプライバシー重視の設計だ。

データ保存の方針

  - メモ内容: 送信後即削除、サーバーには一切保存しない

  - メールアドレス: ローカルストレージのみ、サーバー保存なし

  - 認証情報: 10分で自動削除される認証コード

  - Slack設定: ローカルストレージのみ

 

  セキュリティ対策

  - HTTPS通信の強制

  - CSP(Content Security Policy)の設定

  - 認証コードの試行回数制限

  - レート制限の実装

 

「使う人のプライバシーを守る」ということを最優先に設計した結果、サーバーサイドの実装が非常にシンプルになった。

 

運用してみての感想

実際に使ってみると、「履歴が残らない」という安心感は想像以上に大きい。変なアイデアでも躊躇なく投げられるし、送信後は本当に忘れることができる。

 

オフライン対応も地味に便利で、電車の中で思いついたことを入力しておけば、電波が復活した時に自動送信される。

 

Slack連携は思った以上に重宝している。チーム内でのちょっとしたメモ共有に最適だしリマインドもそこで出来るし余計な機能をこっちで追加しなくてもよい。

 

今後の展望

現状でも十分実用的だが、いくつか改善したい点がある:

  - 音声入力対応

  - ダークモード対応(一応実装済みだが要改善)

  - より高精度な日本語日時解析

  - Carbon Adsでの収益化検討

 

まとめ

「思いついたらすぐ送信、のちに忘れる」というコンセプトで作った投げメモだが、PWAの特性とプライバシーファーストの設計が非常にマッチした。

技術的にも面白い要素が多く、特にCORS問題の解決やローカルファーストの認証システムは良い経験になった。

 

興味のある人は試してみてくださいませ。

[投げメモ]

https://memo.hitoriasobi.life

Keyboard Input Optimization with Karabiner-Elements

ぼくはトグルが嫌いです、日英入力の切り替えが特に…。そんな人(他にいるのか?)にはKarabiner-Elementsを使ったカスタム設定。「左右のCommandキーを日本語入力の切り替えに活用する」方法をご紹介します。


やりたいこと

  • 左Commandキーを英数キーに

  • 右Commandキーをかなキーに

  • ただし、他のキーと組み合わせたときは普通のCommandとして動作

つまり、単独で押したときだけ入力切り替えになるようにします。


設定内容

以下を ~/.config/karabiner/assets/complex_modifications フォルダに .json で保存すればOK。あとはKarabinerの設定画面から有効化すれば反映されます。

{
  "description": "左Command単体押し→英数、右Command単体押し→かな。同時押しなら普通のCommand動作",
  "manipulators": [
    {
      "from": {
        "key_code": "left_command",
        "modifiers": { "optional": ["any"] }
      },
      "parameters": { "basic.to_if_alone_timeout_milliseconds": 300 },
      "to": [
        {
          "key_code": "left_command",
          "lazy": false
        }
      ],
      "to_if_alone": [{ "key_code": "japanese_eisuu" }],
      "type": "basic"
    },
    {
      "from": {
        "key_code": "right_command",
        "modifiers": { "optional": ["any"] }
      },
      "parameters": { "basic.to_if_alone_timeout_milliseconds": 300 },
      "to": [
        {
          "key_code": "right_command",
          "lazy": false
        }
      ],
      "to_if_alone": [{ "key_code": "japanese_kana" }],
      "type": "basic"
    }
  ]
}

この設定のいいところ

  • JISキーボードっぽい操作感がUS配列でも実現できる

  • Commandキー本来の機能もちゃんと生きてる

  • 左右のCommandをうまく使い分けると、指の動きが減ってストレスも激減


まとめ

USキーボードを使っていて日本語入力の切り替えに不満を感じてるなら試してみてください。
Karabiner-Elementsを入れて設定を少しいじるだけで、「英数/かな」問題から解放される世界が待ってます。

プログラム不要のWebアプリ開発時代(←AIがつけたタイトル)

久しぶりにこのブログも書く。ネタも久しぶりにエンジニアとしての内容。

まあエンジニアとしてというか、最近流行りの生成AIを利用しているので自分でプログラムを書かないのでオペレータですが。

 

Bolt.new -> Stackblitz -> Github -> Netlify

(画像、イラスト、その他Bolt.newのAIでは困った場合のセカンドオピニオンとしてChatGPTも利用。ストレージ、認証基盤にはSupabaseも使っている)

 

この連携で一通りのWebアプリ開発から独自ドメインでのサービス提供が可能になってる2024年代。営業、起業と15年以上現場を離れている身からすると、まさにうらしま太郎状態のびっくりもの。自分ではいっさいプログラムは書かない。例えるなら、若くて頭の柔らかい、けどちょっと頑ななところもあったりする20代の物知りエンジニアと知り合って、ひょんな事から一緒に仕事をしているみたい。

もちろん報酬にあたるサービス利用料は各ベンダーに必要だったりするが一ヶ月数万円レベルの範囲内で収まる。多少、プロンプトを上手に書くための工夫は必要で、デバッグで多少のエンジニア的知識、バックグラウンドは必要にはなるが、そこまで深いものは不要。すごい時代になったもんだよ。

そのサービスはまもなく公開予定。ソロキャンパー向けサービス。 

キューバ・リブレが飲みたくなる話し - 「未必のマクベス」

僕はもちろん今まで書評など書いたことは無く、誰に向けての記事なのかも分からないまま書いているのだけど、「未必のマクベス」は良かった。この本に出会えて良かった。

未必のマクベス (ハヤカワ文庫JA)

未必のマクベス (ハヤカワ文庫JA)

 

 帯のコメントに、おすすめの理由が凝縮されていたのでそちらを引用させていただきます。完全に同意です。

「高校時代にちょっと気になる女の子がいて、特になにかあったわけではないのだが、それからも折に触れて彼女を想い出す――そういう経験のある中年男性に本書をすすめたい。あるいは企業の第一線で仕事をしながらも、特に将来を考えず、恋人がいても結婚を夢見ず、そして友人のいない中年男性に本書をすすめたい」

主人公たちは30代後半なので、そこから若干年齢の進んだ40代以降の男性がメインターゲットでしょうか。ハードボイルド小説ですし、人生経験を積んできたオジサンの方が物語に入り易いかも。

物語後半の、優一とある人物との食事のシーンで流れている中国の女性ジャズシンガーBei Xuのアルバム。優一のリクエストで店員にCDを掛けてもらい二人で聴いているのだけど、自分もこの本を読み終えてからその跡をなぞるように聴いて、そのシーンにこっそり同席できた気分で涙。ああ、あの時君たちはこの曲を二人で聴いていたんだな。どうしてこんなに素敵で、切ないんだろう。よかったな、優一・・・涙。

「よかったな、優一」。僕はこの本を読んだ後、物語には登場しない、優一の数少ない友人の一人になったつもりで優一の背中にそう声をかけて、また泣きました。

ロスト・イン・トランスレーション

ロスト・イン・トランスレーション

  • アーティスト: ベイ・シュー,塩田哲嗣,サイラス・チェスナット,ハーリン・ライリー,マサ清水
  • 出版社/メーカー: ユニバーサル ミュージック クラシック
  • 発売日: 2007/01/24
  • メディア: CD
  • クリック: 10回
  • この商品を含むブログ (22件) を見る