LLM Wiki個人開発におけるAIモデル使い分けと開発環境の現在地

monotalk

2026年09月23日

自律型AIエージェントやLLMを活用したナレッジベース「LLM Wiki」の個人開発を進めています。開発を進める中で、「試行錯誤を重ねて綿密に設計した」というよりは、日々コードを書いたり動かしたりしていくうちに、結果として今の開発環境やAIモデルの使い分けに自然と落ち着いてきました。

普段のコード実装であれば Claude Sonnet で十分に事足りると感じていますが、利用を続ける中で「上位の高推論モデルをどのタイミングで投入すれば効果的か」などが自分なりに見えてきました。 2026年9月には Claude Opus 5.5 も登場し、モデルの進化によって使い方は今後も変わっていくと考えていますが、現時点での開発のやり方などをまとめておきます。

1. ベースの開発環境とインフラ構成

まずは、日々の開発を支えているツール群やインフラについてです。全体のアーキテクチャやコスト感を含めて、次のような構成をとっています。

利用しているAIエージェント

Claude Max 20x
Google AI Pro

Claude Max 20xをメインの開発に使い、サブで文章を書いたり、調べ物をする際に、Google AI Proを利用しています。勢いで、Claude Max 20xを契約してしまいましたが、冷静に考えると高いので、もう少し検討しようと思っています。

エディタ環境：Orca

コード編集や日々の開発のベースエディタとしては、VSCode から Antigravity IDE、そして Orca の順に移行してきました。 Orca はbeta版っぽい雰囲気で所々「これ使える機能なのだろうか」という部分はありますが、以下の点が他の環境よりも優れていると感じています。

マルチターミナルでの作業を前提としているUIで、ターミナルの切り替えが直感的に行いやすい。
Git worktreeの利用を前提にしていて、Git worktreeごとにターミナルが開ける。
EditorがターミナルUIと統合されている（少しソースを表示するというレベルの用途であればこれで賄える）。
GitHub IssueやGitHub Projectsが統合されており、ブラウザを開かなくてもIssuesやProjectsを確認・更新できる。
- デフォルトで設定したAIエージェントしか起動できないので、このあたり機能拡張されるとより作業が捗りそう。
スケジュール実行機能を使って、ローカル環境で定期的なエージェントタスクを実行できる。
- 日次でふりかえり、メトリクスなどを抽出させてレポート作成などができる。実行するエージェントも指定可能。

現在は文章を書くために Antigravity IDE を利用していますが、開発作業に関しては Orca に移行しています。以下、Orca の参考記事や公式サイトのリンクを貼っておきます。

参考
- Claude Code 用IDE「Orca」が想像以上によかったので、IssueからPR作成まで試してみた
- Orca — The agent development environment

ホスティングとデプロイ：Cloudflare

アプリケーションやWikiのフロントエンド・エッジ基盤には Cloudflare（Cloudflare Pages / Workers）を利用しています。静的アセットの配信速度やエッジでの柔軟なルーティング、個人開発における手軽さとコスト効率の良さが魅力です。静的なコンテンツ中心だけれど、一部DBを少し使いたいといった用途だと、Cloudflareがとても使いやすいと感じています。

PRなどの開発生産性

日々の開発におけるPRマージ数とIssueクローズ数の推移、およびコミットに関与したAIモデル（Co-Authored-By）の内訳をグラフ化してみました。

日別の開発生産性の推移（PRマージ数とIssueクローズ数）

直近3日間の移動平均（3日おきプロット）で推移を可視化した折れ線グラフです。 8月初旬につくり始めて、PR マージ件数・Issue クローズ件数ともにベースラインが大きく引き上がっております。

日付	PRマージ	Issueクローズ
08/24	7	6
08/25	15	8
08/26	25	3
08/27	2	0
08/28	21	6
08/29	28	5
08/30	28	3
08/31	6	2
09/01	13	10
09/02	14	15
09/03	9	7
09/04	6	3
09/05	21	16
09/06	7	4
09/07	15	87
09/08	16	12
09/09	16	40
09/10	8	5
09/11	16	18
09/12	38	42
09/13	41	39
09/14	47	80
09/15	60	69
09/16	55	54
09/17	20	23
09/18	23	19
09/19	26	86
09/20	61	91
09/21	40	38
09/22	43	115
09/23	59	69

モデル別コミット共著件数（Co-Authored-By）

コミットログ（Co-Authored-By トレイラー）を分析すると、Claude Sonnet 5 が 488 件（約 61%）と大半の日常実装で使っているのがわかります。 2 番目に多い「署名なし（202 件）」は Google AI Pro での Gemini 3.1 Pro や Gemini 3.5〜3.8 Flash による作業です。Claude Opus や Claude Fable をたまに利用する、といった使い方をしています。

2. 個人で継続的に開発していて気づいた AIのモデルの使い方や開発の悩ましいところ

AI活用を前提とした個人開発で変わったと感じる部分や、開発プロセスの変化について記載します。

2-1. AIのモデルの使い方

基本はデフォルトモデルで長く回す

日々の局所的なコード実装やテストの実行、個別バグの修正などは、手軽で安価・高速なデフォルトモデルで長く回しています。最初から高価な上位モデルを使う必要はなく、ほとんどのタスクはこれで十分に進みます。上位モデルを投入するのは、「デフォルトモデルではどうしても立ち行かない」「自分の手が止まってしまい、状況を打破したい」という壁にぶつかったタイミングです。

Claude の使い分け：Claude Code とClaude Cowork

Claude の上位モデルを利用する際は、CLI の Claude Code ではなく Claude Cowork を使っています。その他の通常の開発作業は、CLI の Claude Code で Sonnet 5.0 を動かしています。 Claude Cowork は回答があっさりしすぎず、人間のプロンプトが多少雑であっても文脈を汲み取って粘り強く頑張ってくれる良さがあります。また、構想段階の壁打ちには Claude Cowork の Product Management スキルを活用しています。ブレストのスキルが2種類あり、それぞれ落とし所が違うためレバレッジを効かせやすいです。個人開発だと自分自身がPdMになるので、その壁打ち相手として良いバディーだと感じています。

mattpocock/skills を軸にした開発プロセス

個人的な開発では、最初からがっつり仕様を決めてスタートすることはほとんどありません。かなり緩いIssueを書いて、雑多な要求や課題感を書き出すところから始まります。（緩いIssueすら書けないケースでは、Claude Cowork を利用）

緩いIssueが書けるケースでは、mattpocock/skills のスキルの1つである /grill-with-docs を使っています。

日々の開発はほぼ mattpocock/skills を軸にしています。迷ったときは ask-matt（/mattpocock-skills:ask-matt）でどのスキルを使うか確認しながら進めています。

[粗い要求・Issue起票]
        ↓
  grill-with-docs  (大きめの仕様策定：ADR と CONTEXT.md の生成)
        ↓
     /to-spec  →  /to-ticket  (Issueの分解・整理)
        ↓
    /implement  (実装の実行)

具体的な運用の流れは以下の通りです。

大きめの仕様策定（grill-with-docs）: まとまった機能や構造変更の検討には grill-with-docs を使います。要件の穴を突いてくれるだけでなく、決定事項が ADR（アーキテクチャ意思決定記録） と CONTEXT.md に自然と反映される点が便利です。
Issue の整理と実装（/to-spec, /to-ticket, /implement）: 仕様が固まったら /to-spec で仕様化し、/to-ticket で作業チケット（Issue）に分割します。その上で、各チケットに対して /implement を実行して実装を進めます。
Issue のトリアージとバグ改修（/triage, grill-me）: Issue が溜まってきたら /triage で整理し、分類に応じて grill-me で論点を詰めるか /implement へ回します。バグ改修も grill-me で前提を確認するか、軽微なものは直接 /implement で修正します。

点と点を線で繋ぐ Claude Fable

機能実装やテストを進めていくと、個別の課題や改善点が「点」としていくつも散らばって出てきます。これらの課題を俯瞰し、「線」へとまとめ直す作業で上位モデルを利用しています。モジュールや機能群といった関心事ごとにチャットのコンテキストを切り分け、散らばった課題群を投げて構造化させます。

プロンプトを考えて書くということはしておらず、下位モデルに前提や課題をプロンプトとして下書きさせ、そこに人間が「レバレッジを効かせてくれ」と1行添えて上位モデルに渡す形ですが、結構これで良いです。

以前はこの「点から線へ繋ぐ作業」を人間が頭の中で担っていましたが、人間が考えるとどうしても既存の思い込みやバイアスに引っ張られたり、うまくまとまらず袋小路へ迷い込んだりしがちでした。 AIに俯瞰させると、先入観のないフラットな視点で構造化してくれるため、散らばっていた課題が一本の線として繋がる感覚（手応え）を得られます。

線として繋がった直後の解像度が高いタイミングで ADR を記録し、その後の実装で得られた知見を必要に応じて書き戻すようにしています。

2-2. 開発をしていて感じる悩みや課題

並列作業によるコンフリクトの問題

3-4並列で同時並行にAIエージェントを走らせている際、共通で修正が入るとほぼコンフリクトが発生します。修正した結果をログに記録していたところ、そのログファイルで都度コンフリクトが発生し、修正作業が滞りがちでした。できるだけ修正対象のファイルがコンフリクトしないようにチケットを並べ替えたり、共通モジュール自体を少なくするように工夫しています。

GitHub Actionの利用料金が高くなる

AIエージェントで開発速度が上がると、GitHub Actionの実行回数も比例して増えてしまいます。これで無料枠を超えてしまい、AIエージェントだけでなくGitHub Actionにも課金が必要になりました。遅いCIを高速化するためのチューニングや、GCP上にセルフホストランナーを立てるようにしました。 Google AI Ultra では GCP の $100 クレジットが付与されます。そのため Claude Code メインではなく Antigravity をメインにして、Claude Code をサブにしようかとも考えています。

人間のPRレビューが追いつかない、判断疲れ

1日に50PRくらいある中で、人間がすべてレビューしているわけではないですが、/triage スキルで ready-for-human ラベル（人間の判断が必要なもの）がそれなりに発生します。これは少なからず内容を確認する必要があり、業務後で疲労しているところに輪をかけて疲れます。

おわりに

AIエージェントの導入で開発は格段に早くなりましたが、個人の財布事情を考えると以前よりかなり費用がかさみ、疲労感も強くなりました。ただ、開発が早くなった分、以前は作れなかった規模のものを形にできる面白さがあり、「多少お金はかかるけれど許容範囲」という気持ちになっています。あと、業務上AIを利用して集中して開発することがそこまでなかったので、AI主導で開発するスタイルを手に馴染ませることが直近の体験ではできている気がします。

ただ、業務後に行う趣味としては疲れるので、もう少しAIに完全にお任せできる範囲を増やせるようにガバナンスを効かせていきたいと思っています。