みるみる減っていく利用量ゲージと、それを見て頭を抱える人を描いたアイキャッチ画像

【続報】フェイブル5、丸1日でゲージの8割が溶けた

昨日、「フェイブル5が復活したので布団の中で200ドルプランの解約を相談した話」 という記事を書きました。従量課金になったら桁が合わない、まずは消費ペースを観察しよう、という話でしたね。 で、観察した結果が出ました。早すぎる結果が。 実測値:1日でこうなった フェイブル5が使えるようになったのが7月2日。翌3日の朝8時時点で、私のゲージはこうなっていました。 フェイブル5:79%消費 Opus 4.8:50%消費(昨日リセットされたばかりのはず) 丸1日で8割です。正直に言うと、昨日は「7日までの食べ放題だ」とばかりに、今のうちに頼めることをフェイブル5に頼みまくりました。だから普段より使ったのは確かです。とはいえ、私という人間が1日にこなせる作業量には限りがあるわけで、日常とそこまで大きくは変わらない。それでこの減り方なんだから、フェイブル5はバカ食いする、というイメージは持ちました。 Opusのほうも異常な速さで減っていて、最初は「リセットおかしくない?」と思ったんだけど、これはたぶんカラクリがあります。後述。 使用感のアップデート 昨日は「劇的に良くなった感じはしない」と書きました。1日使い込んだ今の感想は、少しだけ上方修正です。 作業内容としては、だいぶスムーズに動いてくれている感じはします。Opus 4.8よりは、やりとりが少しだけ円滑になった。指示の意図の汲み取りで引っかかる回数が減った、という感覚ですね。 ただ、プログラミングの精度に関しては正直分からない。コードは見るときは見るけれど、その精度までは確認していないし、やりたいことの要望は今まで通り叶っている。今までだって問題なかったので。要望が普通に叶う段階まで環境ができていると、モデルの精度差って体感に出てこないのかもしれない。どうなんでしょうね。 ちなみにAIに叶えてもらっている「やりたいこと」の中身はというと、たとえばこの「タイピングの神様」。フリック入力や文字入力を練習できるアプリです。15年ほど前に作ったんですが、その後は開発のモチベーションが上がらず、長いことレガシーなまま放置していました。それが最近、AIと組むことで蘇りまして、いまは新しいアイデアをあれこれ盛り込みながら手を入れています。 タイピングの神様 フリック入力や文字入力を練習できるタイピング練習アプリ 今すぐ無料でダウンロード App StoreGoogle Play 「Opusまで減ってる」のカラクリ リセット直後のはずのOpus 4.8が1日で50%。最初は不具合を疑ったんですが、仕組みを調べると納得でした。 7月7日までのプロモーション期間中、フェイブル5は週間利用上限の最大50%まで使える。ここがポイントで、これは別枠のボーナスではなく、普段の週間枠の「内数」なんですね。つまりフェイブル5を使えば使うほど、共通の週間ゲージも一緒に削れていく。 フェイブル5はOpusの2倍レートで枠を食う計算になるので、フェイブルに1日振っただけで週間枠が半分吹き飛んだ、と考えるとゲージの減り方と辻褄が合います。異常でも不具合でもなく、仕様でした。 図にするとこういうことです。 タンクは週間枠の1つだけで、ゲージが2本あるように見えるのは分母が違うから。私の場合、フェイブル5で週間枠の約40%を溶かし、Opusでの通常作業が約10%。合計50%が「Opusゲージの50%」で、同じフェイブル分を50%の専用枠を分母にして見ると「フェイブルゲージの79%」になる。2つの数字は、同じ消費の別表示だったわけです。 もし従量課金だったら幾らだったのか 怖いのはここからです。7月8日以降、フェイブル5はこの週間枠から外れて、クレジット(API価格そのまま:入力$10/出力$50 per 100万トークン)でしか使えなくなります。 サブスクからは正確なトークン数が見えないので概算ですが、Max 20xの週間枠まるごとのAPI換算価値は数百ドル規模と言われています。その半分を1日で、しかも単価2倍のフェイブル5で溶かしたとなると、今日と同じ1日を従量課金でやったら数十ドル〜百ドル級は覚悟する必要がありそう。昨日の記事で「海外のヘビーユーザーが1日110ドル溶かした」という報告に触れましたが、あれは他人事じゃなかったですね。 このペースを1か月続けたらどうなるか、サブスクと並べてみるとこうなります。 月200ドルのサブスクなら横一直線のところが、従量課金だと開始2〜4日でその1か月分を突破して、あとは青天井。「桁が合わない」と言われた意味を、グラフにして改めて実感しました。 で、どうするか 昨日の記事では「クレジットを50ドルだけ入れて減り方を観察する」と書きました。が、1日でこの結果を見せられると、正直それすら微妙になってきています。 だって、今日の消費ペースから逆算すると、50ドルなんて下手したら1日分ですよ。1日で7,000円以上。 誤解のないように言っておくと、この値段が高すぎると言いたいわけではないんです。AIは人の何十倍、何百倍と働いてくれるわけで、その成果がそのまま売上につながる人にとっては、1日7,000円なんてむしろ安い投資でしょう。喜んで払う人がいるのも分かる。ただ私の場合、AIで直接儲けているわけではないんですよね。AIが1000倍働いてくれたからといって、私の収益が1000倍になるわけではない。だからこの出費は、投資ではなく純粋な負担としてのしかかってくる。そこの違いなんです。 なので現時点の気持ちとしては、7月8日以降はいったんOpus 4.8中心に戻ることになりそうです。せっかく最強モデルが帰ってきたのに、食べ放題期間が終わったらしばらくお預け。ちょっと寂しくはありますが、提供条件はこの1か月だけでも何度も変わっているので、また気軽に使える日が来るまでの一時的な距離の取り方かなと思っています。 Codexのことを思い出した で、ここで思い出したんですが、私、Codexにも200ドルプランを払ってるんですよね。 以前は100ドルプランだったんだけど、レビューが追いつかなくなって200ドルに上げた。ところが今度は使い切れずに余っている状態。だったらフェイブル5にクレジットを積むより、余っているこっちを活用する方向で進めたほうがいいのかもしれない。 それに今回の一件で思ったのは、Claude Codeにいつまでも頼りきりなのも、それはそれでリスクだなということ。モデルが突然止まったり、課金体系が変わったりするのを目の当たりにしたわけだから、2本立てで回せる体制にしておくのは保険として正しい気がしています。 それにしても月6万円 ClaudeとCodexで200ドル+200ドル、月400ドル。日本円にして約6万円です。「AIに月6万円も払って、私は一体何をしているんだ」と思う瞬間もなくはない。 ただこれ、感覚としては一番近いのはゲーム課金なんですよね。今、私はAIにハマっている。楽しいから払っている。それだけの話で。 しかもこの熱、いつか絶対飽きると思うんですよ。だから今だけ、今だけね、という言い訳めいた後ろめたさ込みでの6万円です。ソシャゲに月6万溶かす人のことを昔は理解できなかったけど、今なら分かる。あれと同じです。違いがあるとすれば、こっちのガチャは回すたびに仕事が進むところくらいで。 だからこそ、というべきか。ゲーム感覚で6万払っている人間ですら、フェイブル5の従量課金だけは「いやそれは無理」となった、という話でした。 おまけ:AIは通信費なのか、掃除機なのか 最後に、今回の一件でぼんやり考えたことを書き留めておきます。 毎月6万円をAIに払う暮らしをしていて実感するのは、AIがもう「あると便利な道具」を超えて、インフラになり得るレベルまで来ているということです。社会のあちこちでAIが組み込まれて、私たちはその上で成り立っている。ロボットも含めて、AIなしでは回らない社会にどんどんなっていくんでしょう。 個人の側でも、私のようにお金を払って日常のタスクを任せる人は、これからどんどん増えていくはずです。感覚としては、お手伝いさんを雇う贅沢というより、掃除機に近い。掃除機がないと掃除がままならないように、AIがないと日常が回らない。そういう位置づけの道具になりつつあるのを、毎日の実感として感じています。 そこでぼんやり考えるのが、AIは暮らしの中でどの位置に収まるんだろう、ということです。道路は国が作る。通信は道路にかなり似たインフラだけど、国が配ることはなくて、各自が通信費を払って使う。掃除機は完全に家電で、国が配るわけがない。当たり前じゃんという話なんですが、じゃあAIはどれに一番近づいていくのか。通信費のような「みんなが個別に払う準インフラ」なのか、掃除機のような「持ちたい人が買う家電」なのか。私の体感は、日に日に通信費のほうへ寄っていっています。 答えの出る話ではないですが、月6万円の請求と引き換えに、その移り変わりのど真ん中を今まさに歩いているようで、ちょっと面白くもあるのです。 ※ゲージの数値は私の環境(Max 20xプラン)での2026年7月3日朝8時時点の実測です。料金・提供条件の公式情報はAnthropic(anthropic.com / support.claude.com)でご確認ください。 参考リンク 前編:フェイブル5が復活したので、布団の中で200ドルプランの解約を相談した話 Anthropic公式 Claude Fable 5ページ (API価格の一次情報) Claudeサポートセンター (プロモーション条件・使用クレジットの案内)

公開: 2026年7月3日 · Toshihiko Arai
夜明けの布団の中でスマホの光を頼りにAIへ相談する人と、料金プランを表す抽象的なモチーフのアイキャッチ画像

フェイブル5が復活したので、布団の中で200ドルプランの解約を相談した話

フェイブル5が今日から使えるようになりました。6月に突然止まって、約3週間ぶりの復活ですね。めでたい。 めでたいんだけど、衝撃の事実がありまして。サブスクで使えるのは7月7日までで、それ以降は従量課金になるそうです。フェイブル5だけね。トークン使用量によってお金を取られる感じ。 で、それがどんなものなのかが分からないので、非常に不安なわけです。 布団の中で相談してみた 今日は5時台に起きて作業してたんだけど、8時ぐらいに頭がすっきりしなくて、もう一度寝たいなと布団に入った。結局寝れなかったので、布団の中からタラタラとAIに相談してました。 相談したのはこういうプラン。 200ドルプランを100ドルプランに戻す。で、浮いた100ドル分を従量課金に回してフェイブル5を使う。今まで通りの感覚でいけるのか? 答えは「桁が合わない」でした。 理由を聞くと、まず私みたいに毎週リミットの90%まで使い倒す人間の消費量は、API換算だと月に数百〜数千ドル相当になるらしい。実際、海外のヘビーユーザーがサブスク内で1日110ドル相当を溶かしたという報告もあるそうで。つまり月200ドルで買ってるのは、従量課金なら軽く10倍以上の値段がつくリソースなんだよね。 しかもフェイブル5の単価はOpus 4.8の2倍(入力$10/出力$50 per 100万トークン)で、おまけにトークン食いが激しい。さらに言えば、100ドルプランの枠は200ドルプランの4分の1しかないから、フェイブル5以前にOpusでの日常作業だけで枠が飛ぶ。 なるほどね。ダウングレード案、あっさり撃沈です。 で、実際に使ってみた感想 今日使った限り、劇的に良くなったという感じはしないね。 結局、指示の勘違いだったりはあるから、そこまでのメリットはもしかしたらないのか、あるのか。 ただこれ、調べてみると私の体感はそんなに外れてないらしい。Anthropic自身が「タスクが長く複雑になるほどフェイブル5のリードは大きくなる」という言い方をしていて、逆に言えば短めのタスクでは差に気づきにくいモデルなんだよね。実務者の評価でも「日常業務の大半はOpus 4.8のほうがコストと速度のバランスで優れる。重く長いタスクだけフェイブル5に振るのが正解」という声が出ている。 私の使い方はまさにその「短め・構造化済み」の側なんだと思う。というのも私の場合、AIにとって使いやすい小道具を先に自前で用意してあるんだよね。テストとかビルドとかリリースみたいな定型作業を、シェルスクリプトで一発で叩けるようにしてある。あとはVPSサーバー上でエージェントをバッチ処理で走らせる仕組み、いわゆるエージェントランナーも組んである。要するに、AIには「考えること」だけをさせて、それ以外の段取りは全部道具側に持たせている状態。そういう骨組みを固めたうえで指示を出してるから、Opusでもかなりスムーズに行ってる。フェイブル5の売りである「自分で計画して、自分でテストして、自分で検証する」の部分を、私はすでに自前の仕組みでやらせているわけで。だとすれば差が出にくいのも道理かなと。まあこれは私の仮説で、逆に数日がかりの自律タスクを丸投げしたら評価が変わる可能性は全然あります。まだそういう使い方はしてないので。 あともうひとつ、復活後のフェイブル5には強化された安全分類器が入っていて、日常的なコーディングやデバッグでも無害なリクエストが誤検知されることがあり、その場合は裏でOpus 4.8が応答する仕組みになってるらしい。95%以上のセッションはフェイブル5自身が答えているそうだから多くはないんだろうけど、「今日の返事、実はOpusだった」可能性も一応あるわけです。 結論というほどでもない結論 200ドルプランは維持 従量課金のクレジットは最初50ドルだけ入れて、減り方を観察 フェイブル5は「ここぞ」というタスク専用 いずれにせよ、今後はどんどんフェイブル5以上のものが出てくるだろうし、フェイブル5がサブスクラインで使える日も来るだろうとは思うんだよね。Anthropic自身も「容量の問題で、できるだけ早くサブスクに戻したい」と言ってるみたいだし。だから時間が経つにつれ、ますます使いやすくなる未来は予想できます。焦って課金を積む必要はないかなと。 それはさておき ハーモナイズの課金をしてくれた人がいました。デベロッパー支援で1000円のコーヒー、真ん中のやつですね。ありがとうございます。日本の方でした。こういうのがあると、布団から出る気力が湧きます。 そのハーモナイズも含めて、最近はこのクロードで自分のアプリ開発をどんどん進めています。フェイブル5だ従量課金だと気を揉んではいますが、結局いちばん実感しているのは、AIと組んでからの開発の速さです。ハーモナイズを直しながら、別のアプリの機能追加も並行で走らせて……という具合に、一人でも複数の作業が同時にどんどん片づいていく。朝に布団の中で相談したことが、その日のうちに形になっていることも珍しくありません。値段のことで文句を言いつつも、この身軽さはもう手放せないな、というのが正直なところです。 ハーモナイズは無料で遊べる音感トレーニングアプリです。よかったら触ってみてください。 Harmonize 相対音感と純正律の感覚を鍛える音感トレーニングアプリ 今すぐ無料でダウンロード App StoreGoogle Play 参考リンク Anthropic公式 Claude Fable 5ページ (API価格、セーフガード、Opus 4.8へのフォールバックの説明) Anthropic公式ニュース (提供再開と7月7日までのスケジュールに関する発表) Claudeサポートセンター (使用クレジットの購入・自動チャージの設定方法) ※料金・提供条件は2026年7月2日時点の情報です。

公開: 2026年7月2日 · Toshihiko Arai
自前のForgejoサーバーを捨て、GitHubとClaude Codeのスマホ運用へ移行する流れを表した図

自前Gitサーバー(Forgejo)でAIエージェント基盤を作って、3日で捨てた話

AIエージェントに開発を任せる仕組みを「どこまで自前で持つか」で悩んでいる人向けの記録です。結論から言うと、私はローカルForgejoでの完全自前運用を一度組み上げ、そして捨てました。捨てて初めて分かった「管理を手放す価値」と、その先で出会ったスマホ運用のパラダイムシフトまでを、時系列で残します。 これは「やってみてうまくいった成功談」ではなく、「作り込んで撤退した正直な記録」です。3日かけて組んだものを3日で捨てたので、その判断に至るまでの過程と、そこで得た教訓を共有します。 きっかけは、以前作った agent runner だった そもそもの出発点は、以前作った GitHub IssueからCodexを動かすagent runner でした。 GitHub Issueをキューにして、VPS上のrunnerがそれを定期的に拾い、Codex CLIを非対話で実行してPRまで作る。ターミナルに張り付かなくても、スマホからIssueを投げれば作業が進む。ここまでは確かに動いていて、私の開発体験は一度大きく変わりました。 ただ、AIエージェントを使い込むほど、人は欲が出てきます。「この仕組み、もっと自分の手元に寄せられないか」と。そこから今回の迷走が始まりました。 GitHubのIssueが使いづらくて、自分で作り始めた そもそもの発端は、もっと素朴な不満でした。GitHubのIssueが、どうにも使いづらかったのです。 動作がなんとなくもっさりするし、リポジトリが増えてくると「これはどのリポジトリのIssueだったか」が分かりにくい。実際、別のリポジトリにIssueを書き間違える、というミスが何度も起きていました。 それで、こう思ったのです。「Issueくらいなら、自分で作ってローカルサーバーに立てておけばいいのでは」と。さっそく、AIエージェントの力を借りて、Issue管理の仕組みをさくっと自作しました。 ところが、作っているうちにスコープがどんどん膨らんでいきます。Issueがあるなら、プルリクエストも要るのではないか。PRがあるなら、差分を確認する仕組みも要るのではないか。AIエージェントがIssueを読み込むところまではいいとして、その後のPRやレビューのやり取りは、いったいどう作ればいいのか。 考えているうちに、はたと気づきました。これは結局、GitHubそのものを作ろうとしているのではないか、と。 であれば、答えは単純です。同じものがOSSにあるなら、それを使えばいい。そこでOSSの Forgejo を採用しました。ForgejoはGiteaから派生した、セルフホスト前提のGitフォージです。GitHubに近いIssue・PR・Webhookの機能が一通りそろっています。 根っこには、外部サービスへの依存を切りたい、全部を手元に置きたい、という気持ちもありました。実行時間の枠や無料プランの制約、コードやIssueを外部に預けることへのうっすらとした抵抗。そして正直に言えば、「この仕組みを一から自分で組んでみたい」という技術的な好奇心も、大きな燃料だったと思います。 そこでローカルにサーバーを立て、Forgejoをインストールしました。ただ、立てて動かすまでにも、地味な手間が少しずつ積み重なります。APIトークンや権限まわりの設定、サーバーとして動かし続けるための構築と運用。意外なことにWebhook連携そのものは素直に動いたのですが、「GitHubなら最初から用意されていたもの」を一つずつ自分で揃え直している感覚は、この時点ですでにありました。 「これでGit基盤も含めて、開発のループが全部自分の管理下に入る」——そう思っていました。 ClaudeとCodexで「3往復の自動レビュー」を組んだ Forgejoを土台に、私は前回のrunnerをさらに進化させた「エージェントランナーv2」を組みました。 流れはこうです。 ForgejoにIssueを書く そのタイミングでWebhookが発火し、処理が起動する Claude CodeがIssueを読み取る そのままClaude Codeが実装まで進める その実装を内部でCodexにレビューさせる このレビューのやり取りを最大3回まで自動で往復させる 完成したらIssue/PRにコメントで結果を返す ポイントは、AI同士が互いをレビューし合う閉ループを自動で回す構造にしたことです。Claudeが実装し、Codexがレビューし、また直す。前回の記事で AIエージェント自身がテストを実行して直す閉ループ の話を書きましたが、それを「実装者AI」と「レビュアーAI」の二者間にまで広げた形になります。 Issue → PR → レビュー往復 → コメントに記録を残しつつ手元に戻る。図にすると一本の気持ちのいいパイプラインで、組んでいる間はかなり楽しかったです。 つまずいたのは「どのサーバーに置くか」だった ところが、組み上げた直後から現実的な問題が頭をもたげてきました。「これ、結局どのサーバーで動かし続けるのか」という問題です。 最初はローカルのマシンに置きました。しかしローカルに置いたままでは、外出先など別のネットワークからは叩けません。そこで VPN でつなぐことを考え、Tailscale を試しました。手元のマシン同士を VPN 網で直接つないでしまえば、外からでも安全にアクセスできます。 ただ、普段使いの Mac のバックグラウンドで VPN クライアントが常駐し続けるのが、どうも好きになれませんでした。ならばと、VPS 側に Tailscale を入れて、運用一式を VPN ネットワークの中に閉じ込めてしまえば安全ではないか——と考えて構成してみました。 しかし実際にやってみると、これがなかなか雑で、手間のかかる構成でした。管理する箇所もトラブルの種も、明らかに増えていきそうです。結局、この VPN 構成は廃止しました。 ...

公開: 2026年6月1日 · Toshihiko Arai
SuperMemo ― ロック画面が最速のメモになる

スーパーメモ開発者インタビュー|ロック画面メモアプリを8年間作り続けた個人開発者に聞く

インタビュアー: 黒堂 光人(フリーランスライター/テクノロジー・個人開発専門) インタビュイー: Toshihiko Arai(スーパーメモ 開発者) Q1. スーパーメモをひと言で表すとしたら、どんなアプリでしょうか? 通知センターの仕組みを活用して、ロック画面にメモを残せるアプリですね。 Q2. そのアイデアはどこから生まれたのでしょうか?どんな「困りごと」や「気づき」がきっかけでしたか? 10年前とか、アップルウォッチってまだなかったでしたっけ?あの頃はスマホをポケットに入れていましたよね?買い物中にスマホを出してメモを確認するためには、ロック画面を解除して、目的のアプリを開いてメモを確認するみたいな数個のアクションが必要でした。そこでワンアクションで確認できるメモが必要だったのです。特に買い物中は、カゴを持ったりと忙しいですから。片手操作でサクッとメモを確認できないかな?そう思ったんです。 Q3. 最初のバージョンはいつ頃リリースしたんですか?その頃の手応えはどうでしたか? 初回のリリースが2018年9月でしたね。もう8年前にもなるんですね。手応えはなかったですよ。今でもないんですが(笑) アプリもレッドオーシャンで、ありとあらゆるアプリがリリースされている感があって。世の中にはメモアプリがたくさん溢れている。そんな感じでしたから。 Q4. 手応えがない中でも8年間続けてこられた理由は何ですか? いや、続けてきたというか……放置してました(笑) ほとんど使われてないんだろうなという認識でした。でも自分にとってはたまに使ったり使わなかったり。なんだかんだ愛着があったのかもしれません。最近では母親も使うようになっていて。特に教えたわけではないのですが、母は勝手に自分のアプリをチェックして使ってくれてるみたいです。母でも使いやすいならやっぱ開発のスタイルは間違ってなかったのかななんて。利用者は少なくても、アプリのコンセプトには自信を持ってましたね。 Q5. 「放置していた」とおっしゃっていましたが、最近また開発に力を入れ始めたきっかけは何かあったんですか? やっぱりAIのおかげですね。遅ればせながらClaude CodeやCodexを実際使ってみて、一気に改修作業が楽になりました。さっきも言った通り、ほとんど人気のないアプリでしたから、改修課題をGitHub Issueにあげてはいたものの、自分でプログラミングするのが億劫で……ほぼ放置状態でした。ところがClaude CodeでAI駆動開発、というんですか?AIベースで作業するようになったら楽しくなっちゃって(笑) Q6. Claude Code を使い始めて、開発のやり方や進め方は具体的にどう変わりましたか? まずXcodeなどIDEを立ち上げることがほとんど皆無になりました。自分ではプログラミングはしません。改善点や機能追加の要望をGitHub Issues へ貯めておいて、それをCLIでClaude Codeに依頼し実装まで進めてもらいます。実機動作は私がしっかり確認し、改修ポイントのソースコードも問題なさそうだなと判断したら、PRレビューまで持っていきます。レビューに関してはVPS側でポーリングによるCodexレビューの仕組みを独自に作りました。そのレビューへの返答を再びClaude Codeへ任せる、といった感じですね。一人でプログラミングもレビューも検証もやっていた頃とは、開発スタイルは大きく変わりました。 Q7. そのワークフローの中で、Toshihikoさん自身が「ここだけは人間がやるべき」と感じている部分はどこですか? うーん、難しい質問ですね……。アプリ開発初期段階からAIベースで開発しているわけではないので、既存のアプリの使用感を崩さないように、私が実機での動きを確認する作業が残っています。他の部分はほとんどAIに任せられるのではないでしょうか?もっと言えば、今はAIが情報空間だけのやりとりに閉じられてしまってますが、今後、視覚や実機操作もこなすロボットになって空間情報もフィードバック可能になれば、検証だって任せられると思います。とは言えその頃は、人間がアプリを使ってメモするみたいな慣習も大きく変わっているでしょうけれど。あとは、セキュリティ面やデータ管理で問題がないか気にしますかね。やっぱり人間のユーザーさんが向こう側にいるというのは、個人開発であっても、ちゃんと責任を感じています。 Q8. スーパーメモはCSVでデータを管理しているというのが技術的にユニークですが、なぜデータベースを使わずにCSVにしたんですか? 当時読んだ、個人開発者が億を稼いだときの裏話的な本に影響を受けたからですね。CoreDataなどDBを使ってリリースしてたアプリはあったんです。当然メモアプリを作る際もその選択を考えたんですが、その本によると結局DB管理するとマイグレーション問題が大変で。特にWEBアプリじゃないから、ユーザー側のDBスキーム更新ってどんな挙動するか予想がつきませんよね?バージョンをすっ飛ばして最新のスキームを入れてしまったらどうなるんだろうとか……正直、そこまで管理するのは手に余る感じがして。そこで書籍にあったのが、テキストベースでシンプルな管理方法だったんです。ゲームアプリでしたが、DBなど使わず永続化はテキストベースという割り切り方で。そのころの自分の悩みとぴったり一致して、目から鱗でしたね。 Q9. 8年間アプリを育ててきて、ユーザーから届いた反応や声で、一番記憶に残っているものはありますか? 思ったよりも、通知センターのバナーに表示される便利さをちゃんと理解して使ってくれているユーザーが多かったことですかね。レビューでの声を見る限り。あとは外国人も意外と使ってくれているんだなと。「Simple is best」という言葉をいただいたんですが、確かにそうだなと。AI活用でますます多機能なアプリが出てくる時代だからこそ、スーパーメモはシンプルをこれからも貫いていこうと思いましたね。 Q10. 現在のスーパーメモに、Toshihikoさん自身が「ここはまだ不満だな」と感じている部分はありますか? ほぼ完成系なので個人的な不満はないのですが、強いて言えば先ほどのテキスト管理 vs データベースの問題ですかね。テキストベースなのでこれ以上複雑なことをするにはリスクが高くなります。例えば画像を添付したメモも開発したいという構想があるのですが、それをやるにはDB管理の方が良さそうだなと思ったりしてます。でも、「その機能本当にいるの?」とテキスト管理が問いかけてくれるので、シンプルさを維持できているという見方もあるのかなと(笑) Q11. 画像添付のような「やりたいけどやっていない機能」は他にもありますか?あるとしたら、何が優先度を決めるんですか? 次回リリース時に盛り込む、ホーム画面のウィジェット機能ですかね。ホーム画面でメモが見れるようになります。通知バナーと同じで、メモ確認へのアクセスのアクション数を少しでも減らせれば、それは優先度高く実装したくなりますね。 Q12. Apple Watch への対応はいつ頃で、どんな経緯で実装したんですか? 昔から構想はあったんです。でも自分で調べて開発するには腰が重くてね。AI駆動開発ならサクッと実現できるかなと思いまして。そのために久々にアップルウォッチを買っちゃいましたよ(笑) 昔のウォッチよりバッテリー持ちが良くて好印象です。スーパーメモに限らず、ウォッチ開発でいろいろアイデアを試せたら楽しそうだなという気持ちもありますね。 Q13. 時間やモチベーションの管理はどうしていますか? AI駆動開発を知ってから1カ月ちょっとたったくらいでしょうか?とてつもないパラダイムシフトが起きている感じがして、飽きるどころかAIへのプロンプトや仕組みを調整するのに手がいっぱいですね。アイデアをすぐに実現してくれるので、モチベーションがどうこうというより、次に何をしようか考えるのに必死という感じで、AIに翻弄されていますよ(笑) あとは、パソコンに張り付く時間が長くなった気がするので、個人開発用のパソコンは立ち作業でやってます。MacBookを台の上に置いて立ちながらタイピングできるようにして、指示待ちの時間に部屋をウロウロしながらアイデアを考えたりできて、健康にもいいかなって(笑) アップルウォッチのヘルスアプリで歩数を確認したら、部屋の中だけで1万歩近く歩いている日もありました。通常でも5000歩は歩く感じですね。 ...

公開: 2026年5月26日 · Toshihiko Arai
CLAUDE.md・Issue・Skill の役割をカード形式で比較した図

Claude Code の Skill・Issue・CLAUDE.md の使い分けを整理した

Claude Code を使い始めてしばらく経ち、Issue ベースで作業を指示するフローは固まってきた。そこで気になっていた Skill という仕組みを調べた。「繰り返し依頼に便利」とは聞いていたが、実際に何をするもので、Issue や CLAUDE.md と何が違うのかを整理しておきたかった。 Skill とは何か Skill は .claude/skills/<skill-name>/SKILL.md の形で置く Markdown ベースの追加手順だ。ファイルには YAML front matter の description と、実行時の指示を書く。 呼び出され方は2通りある。 Claude Code が description を見て関連すると判断したとき、自動で読み込む ユーザーが /skill-name の形で明示的に呼び出す Skill ディレクトリにはテンプレートや参考資料、スクリプトも同梱できる。プロジェクト単位・個人環境単位のどちらにも置ける。 公式ドキュメントでは、同じ指示やチェックリストを何度もチャットに貼っている場合や、CLAUDE.md の一部が事実ではなく手順書になってきた場合に Skill 化するとされている。本文は使われるときだけ読み込まれるため、長い参照資料を常時コンテキストに入れずに済む点がメリットだ。 Commands との関係 以前は .claude/commands/deploy.md という単一ファイル方式のカスタムコマンドがあった。現在は Skills に統合されており、どちらも /deploy のようなスラッシュコマンドとして動く。 方式 パス 特徴 Commands(旧) .claude/commands/deploy.md 単一ファイル、シンプル Skills(現在推奨) .claude/skills/deploy/SKILL.md ディレクトリ構造、自動呼び出し対応 既存の .claude/commands/ は引き続き動作するが、新しく作るなら .claude/skills/ が推奨だ。 Skill の書き方 SKILL.md の構造 SKILL.md は2つのパートで構成される。 --- name: gen-test description: テストを生成する disable-model-invocation: true --- 以下のファイルのテストを生成する: $ARGUMENTS 1. ソースファイルを読む 2. テスト対象の関数を特定する 3. プロジェクトの規約に沿ったテストを書く --- で囲まれた上部が frontmatter で、Claude に「この Skill をいつ・どう使うか」を伝える設定欄だ。YAML 形式で書く。--- 以降が実際の指示内容になる。 ...

公開: 2026年5月20日 · Toshihiko Arai
macOSの画面右上にClaude Codeの作業完了通知が表示されているイメージ

Claude Codeの作業完了・許可待ちをOS通知で受け取る設定方法

Claude Code に作業を任せて別のことをしていると、いつの間にか完了していたり、許可プロンプトで止まっていたりすることがある。 「通知が来れば気づけるのに」と思って設定を試してみた。結果としては動くのだが、期待していたほどスムーズではなかった。以下は試行錯誤の記録として参考にしてほしい。 組み込み設定とその限界 Claude Code には preferredNotifChannel という組み込みの通知設定がある。 { "preferredNotifChannel": "auto", "inputNeededNotifEnabled": true } ただしこれは iTerm2 の通知機能を経由するため、セッション名や生のエスケープシーケンスがそのまま通知に表示されることがある。複数プロジェクトを同時に動かしていると通知が混在して読みにくくなる。 hooks で osascript を使う 組み込み設定に限界を感じたので、~/.claude/settings.json の hooks を使って macOS ネイティブの通知を直接出す方法も試してみた。 { "hooks": { "Stop": [{ "hooks": [{ "type": "command", "command": "osascript -e \"display notification \\\"作業が完了しました\\\" with title \\\"Claude Code [$(basename $PWD)]\\\" sound name \\\"Glass\\\"\"" }] }], "Notification": [{ "hooks": [{ "type": "command", "command": "osascript -e \"display notification \\\"入力が必要です\\\" with title \\\"Claude Code [$(basename $PWD)]\\\" sound name \\\"Ping\\\"\"" }] }] } } Stop は Claude が作業を終えたとき、Notification は許可プロンプトや質問で入力待ちになったときに発火する。 ...

公開: 2026年5月19日 · Toshihiko Arai
CLI AIとMakefileからiOSビルド、実機デプロイ、テスト、スクリーンショット生成へつながる図

AI時代にmakeコマンドが便利すぎる。CLI AIとiOS開発をつなぐ操作盤として使う

AIエージェントを使うようになってから、古くからある make コマンドの便利さを改めて感じている。 make は C 言語のビルドで使う古い道具、という印象が強かった。自分も昔から知っていたが、仕組みをきちんと理解して使っていたわけではない。 ところが、Claude Code や Codex のような CLI 型 AI エージェントを相棒に開発すると、make はかなり相性がいい。 理由は単純で、プロジェクトでよく使う操作を make test、make build-release、make device-debug のような短いコマンドにまとめられるからだ。人間と AI エージェントが同じコマンドを見て、同じように実行できる。 特に iOS アプリ開発では効果が大きい。make device-debug でビルド、実機インストール、起動までできるようにしておくと、Xcode を開かずにターミナルだけで開発を進められる場面が増える。Xcode は他の IDE と操作感がかなり違い、毎回開くのが負担に感じることもある。Xcode への依存を半分でも減らせると思うと、iOS アプリ開発の心理的なハードルも下がる。左半分のターミナルで Claude Code などの CLI AI と対話し、右半分や別タブで make を叩く。あるいは AI エージェント自身に make test を実行してもらう。 GitHub Issue とターミナルがあれば、基本的な開発作業がかなり済んでしまう。 makeは何をする道具なのか make は、Makefile に書かれたルールを読んで、必要なコマンドを実行する道具である。 GNU Make のマニュアル では、make は大きなプログラムのどの部分を再コンパイルする必要があるかを自動判定し、そのためのコマンドを実行するユーティリティとして説明されている。 もともとの発想は、ファイル同士の依存関係を見て、変更があった部分だけを更新することだ。 たとえば C の世界なら、main.c から main.o を作り、複数の .o をリンクして実行ファイルを作る。ヘッダーファイルが変わったら、それに依存するソースを再コンパイルする。こういう関係を毎回人間が覚えて実行するのは面倒だし、間違いやすい。 ...

公開: 2026年5月17日 · Toshihiko Arai
Codex、Claude、iOSアプリ開発の3つが淡く重なり合う抽象的なアイキャッチ画像

【新規記事】AIエージェントに没頭した20日間。Codex、Claude、iOSアプリ開発まで

ここ最近、AIエージェントをかなり集中的に触っていた。 Codex の $100 プランを契約し、20日ほどがっつり使ってみた。 結論から言うと、来月からは $20 プランへ戻す予定である。 理由は単純で、$100 プランの容量を使いこなすほど、自分の指示が追いつかなかったからだ。 Codex が物足りなかったわけではない。 むしろ十分すぎた。 5日のコンテキスト上限を使いこなすほどの指示を、自分が出せなかった。 つまり、自分の処理能力が先に限界へ来た。 CLI型AIエージェントのすごさは「フィードバックループ」にある Codex に限らず、この手の CLI 型AIエージェントを導入してすごいと思ったのは、ローカルプロジェクトを理解してくれることだった。 これまで Web ブラウザ版の ChatGPT を使ってコード修正を相談する場合、修正したいファイルを毎回アップロードしたり、コードを貼り付けたりする必要があった。 しかし CLI 型AIエージェントでは、ローカルのプロジェクトをそのまま見てもらえる。 そのため、プロジェクト全体をまるで把握しているかのように、かなり的を射たコーディングをしてくれる。 ただ、改めて考えると、すごさはそれだけではない。 もっと大きいのは、AIエージェント自身がテストコードを実行できることだと思う。 AIがコードを改修する。 そのコードに対してテストを実行する。 テストが失敗したら、エラー内容を読んで、もう一度コードを直す。 そしてまたテストを実行する。 これは、単なるコード生成ではない。 入力に対して出力を返すだけではなく、その出力結果を観測し、フィードバックして、次の修正に反映する流れである。 制御工学っぽく言えば、開ループではなく、閉ループになった感じがある。 これまでのAIチャットは、どちらかといえば「コードを提案して終わり」だった。 しかし CLI 型AIエージェントでは、生成したコードを自分で実行し、結果を見て、自分で修正する。 このフィードバックループが入ったことで、AIによるコーディングはかなり実用的になった。 人間に例えれば当たり前の話だが、たったこれだけで、精度はぐんと上がった感がある。 (このことは、今後 AI をうまく使いこなすための大きなヒントになるかもしれない) もちろん、すべてが完璧になるわけではない。 テストが通っても、仕様として正しいとは限らない。 こちらの気持ちや意図まで理解するには程遠い場面も多々あり、最後は人間による判断が必要になる。 それでも、テスト結果という強いフィードバック信号をAI自身が扱えるようになったことは、かなり大きな変化だと思う。 Claude も契約してみた 一方で、Claude の $20 プランも契約してみた。 CLI AI エージェントは Claude が先駆者だと思うが、Codex を先に体験してしまったので、Claude を使うことに今更感があり少し足踏みしていた。 しかし、実際に使ってみると Codex との違いを比較できて、かなり面白かった。 ただし、契約時にはクレジットカード決済で少し苦労した。 なかなか決済が通らず、最終的には VISA の楽天カードについてサポートへ連絡し、ストップされていた件を説明して解除してもらうことで、ようやく決済できた。 ...

公開: 2026年5月9日 · Toshihiko Arai
多窓ターミナルの旧世界からGitHub IssueキューとVPS上のagent runnerへ世界線が切り替わるイメージ

GitHub IssueからCodexを動かすagent runnerを作ったら世界線が変わった

この記事で伝えたいこと Codex などの AI コーディングエージェントを使うと、コードを書く時間そのものは短くなる。一方で、実際に使い込むほど「エージェントへ指示を出す」「結果を確認する」「失敗したら再実行する」「別の作業をもう一つ投げる」といった運用に時間を取られるようになった。 気がつくと PC の前に張り付き、ターミナルを 4 窓から 8 窓くらい開き、どの作業がどこまで進んでいるのかを追い続けていた。これはこれで便利ではあるが、開発体験としてはまだ人間がかなり忙しい。 そこで、GitHub Issue をキューとして使い、VPS 上の agent runner が Codex CLI を非対話で動かす仕組みを作った。この記事ではプログラムの細部ではなく、なぜ作ったのか、GitHub Actions と何が違うのか、どんな構成で動かしているのか、そして何が変わったのかを整理する。 「agent runner」 はあくまで自作のプロダクト名であり、前回の記事 さくらのサーバーでCodexをcronで動かしてブログ記事を自動リライトさせる をさらに進化させた形である。 想定読者 この記事は、すでに AI コーディングエージェントを使っている開発者に向けて書いている。 特に次のような人を想定する。 Codex CLI や Claude Code などのエージェントを日常的に使っている ターミナルを複数開いて並行作業している GitHub Issue や PR を開発の入口として使っている CI/CD とは別に、AI エージェントへの作業依頼をうまく管理したい 導入: AI 駆動開発は便利だが、人間が忙しい AI コーディングエージェントを使うと、実装、調査、テスト修正、ドキュメント作成などをかなり任せられる。 ただし、使えば使うほど別の課題が出てくる。 ターミナルをいくつも開いて、複数のエージェント作業を見張る必要がある どの作業に何を指示したか分からなくなりやすい 失敗した作業を再投入するたびに、文脈を思い出して指示し直す必要がある PC の前にいないと、次の指示を出しにくい エージェントは作業を進めてくれる。しかし、作業を投げる入口がターミナルに閉じていると、人間は結局ターミナルの前から離れにくい。 この状態を変えたかった。 なぜ Codex GitHub Action ではないのか 最初に考える選択肢は GitHub Actions だと思う。GitHub のイベントをトリガーにして処理を走らせるなら、Actions は自然な選択肢だ。 ...

公開: 2026年5月5日 · Toshihiko Arai
サーバー上のcloneリポジトリでCodexが安全な作業ブランチを動かしているイメージ

さくらのサーバーでCodexをcronで動かしてブログ記事を自動リライトさせる

ブログ記事の簡単なリライト作業を、手元のMacではなくサーバー側でも動かすようにしてみました。 やりたいことは、サーバーにブログ用リポジトリを clone して、その中で Codex CLI に記事リライト系の作業を任せ、さらにコミット・push・PR作成までを自動化することです。 実際には gh の権限、privateリポジトリのclone、Codexのログイン、sandbox など、細かいところでつまずいたことがいくつかありました。それらを中心に、備忘録として残しておきます。 やりたかったこと まずはサーバーにSSHでログインし、GitHubリポジトリを用意します。 仮に、clone先は以下とします。 /home/appuser/repos/private-blog ここにブログのprivateリポジトリをcloneして、記事リライト用のバッチ処理から Codex CLI を呼び出します。最終的には、このバッチ処理をcronで定期実行する想定です。 当然、git / gh / codex がシェルで使えるように、サーバー側へ各コマンドをインストールしておく必要があります。 本番サーバーでやるのが怖い場合は、もう1台サーバーを用意するのも現実的です。さくらVPSなら比較的安いですし、私も本格運用するなら別サーバーを用意する予定です。 もちろん、ラズパイなどを使って自鯖で処理させるのも十分ありだと思います。 サーバー側でCodexに作業させるので、本番公開ディレクトリとは必ず分けておきます。 /home/appuser/public-site # 公開用 /home/appuser/repos/private-blog # 作業用clone また、私の場合は、リポジトリのmainブランチも直接編集させず、worktreeを使った別ブランチで作業させるようにしています。 全体の関係は、次のようなイメージです。 今のところ、PRのレビューからbuild / deploy作業までは、人間が担当するようにしています。 そのためローカルMacの出番は、最初の初期設定とPR確認が中心です。そこまで整えば、毎回SSHでサーバーに入って手作業する必要はかなり減ります。 なぜGitHub Actionsではなくサーバー上のcloneで回したか ところで、この手の自動化をChatGPTへ相談すると、かなりの確率で GitHub Actions 案が出てきます。 MicrosoftはGitHubを買収済みで、OpenAIにも大きく投資しています。 Microsoft → GitHubを買収済み Microsoft → OpenAIへ大規模投資 だからActionsが推されるのでは、と邪推したくなるくらい毎回出てきます。もちろん半分冗談です。実際には、定期実行やPR作成までGitHub側で完結できるので、CI/CDの定番案として出てくるのだと思います。以前、VPSへのデプロイでは GitHub CI/CD で VPS へ自動デプロイするまで にまとめたように、Actionsの便利さも確認しています。 それでも今回は、サーバー上のcloneで動かす方を選びました。 理由は主に3つです。 1つ目は、すでにサーバー上で日次処理を動かす前提があったことです。記事リライトはサイト運用のローカルな作業に近く、実行ログや失敗時のworktreeをサーバー上に残せる方が追いやすいと考えました。 2つ目は、秘密情報を増やしたくなかったことです。GitHub Actionsに渡すsecretを増やすより、サーバー側のenvファイルに閉じた方が、今回の小さな運用では見通しがよくなります。 3つ目は、OpenAI API key を新しく使わずに進めたかったことです。Codex CLIはChatGPTログインでも使えるため、今回の確認ではAPI keyを新規発行せず、手元で使っているアカウントのログインで試しました。もちろん、公式にはAPI key認証もあり、CIや完全自動化ではAPI keyの方が向く場面もあります。ここでは「今回の運用では使わなかった」という整理です。 ...

公開: 2026年5月2日 · Toshihiko Arai