- LLMを活用したソフトウェア開発において、アーキテクト・開発者・レビュアーのマルチエージェント・ワークフローにより、数万行規模のプロジェクトを低い欠陥率で維持する具体的な方法論を共有
- プログラミングそのものよりも何かを作ることに関心があり、LLMがコーディングをうまくこなすようになったことで、作ることに集中できるようになった
- コードを書く能力よりも、システムアーキテクチャの設計と正しい選択を下すエンジニアリングスキルのほうがはるかに重要になった
- 異なるモデルを組み合わせて使うことでコードレビューの品質を高め、各モデルの強みと弱みを役割ごとに分離して活用
- 実際のメール機能追加セッション全体を公開し、アーキテクチャ決定からQAまで、人間主導のLLM協業プロセスを詳しく記録
LLMで作ることの利点
- プログラミングが好きだと思っていたが、実際には作ることそのものが好きで、LLMがプログラミングをうまくこなすようになってからは、ひっきりなしに何かを作っている
- Codex 5.2のリリース前後、そして最近のOpus 4.6に至って、非常に低い欠陥率でソフトウェアを書けるようになった。自分で手を動かしてコーディングするより、欠陥率が有意に低いことすらある
- 以前は2〜3日作業するとコードが保守不能な状態に陥っていたが、現在は数週間連続で作業しながら、数万行の有用なコードを安定して育てている
- エンジニアリングスキルが不要になったのではなく、求められる場所が移動した。コードを正しく書く能力の代わりに、システムを適切にアーキテクトし、実用的なものにする判断力が中核になっている
- 基盤技術をよく理解しているプロジェクト（例: バックエンド）では数万SLoCでも問題ないが、よく知らない技術（例: モバイルアプリ）では、依然として誤った選択の蓄積でコードがひどい状態になる
- LLMの初期（davinci以降）にはすべてのコード行をレビューする必要があり、その後の世代では関数単位、今ではアーキテクチャ全体のレベルだけ確認すればよい流れになっている。来年にはそれすら不要になるかもしれない
この方法で作ったプロジェクト
- Stavrobot: セキュリティ重視のLLMパーソナルアシスタント。カレンダー管理、空き時間の判断、リサーチ、コード作成による自己拡張、リマインダー、家事の自律管理などを行う。1つのキラー機能ではなく、何千もの小さな不便を解消することが中核的な価値
- Middle: 音声メモを録音してテキスト化し、Webhookで送信する小型のペンダントデバイス。常に持ち運べて、摩擦なく使えることが重要
- Sleight of Hand: 秒単位では不規則にカチカチ鳴るが、分単位では常に正確な壁時計アートプロジェクト。500ms〜1500msの可変ティック、知覚しにくい速度変化の後のランダム停止、倍速で進んで30秒待機するなど、さまざまなモードを備える
- Pine Town: 無限マルチプレイヤーキャンバスで、それぞれが小さな土地を与えられて絵を描くインタラクティブな草原プロジェクト
- これらすべてのプロジェクトをLLMで作っており、コードの大半を自分で読んだことはないが、各プロジェクトのアーキテクチャと内部動作はよく理解している
ハーネス（Harness）ツール
- ハーネスとしてOpenCodeを使用しており、Piでも良い経験があった
- ハーネスに必要な条件は2つある:
- 複数企業の多様なモデルが使えること: ほとんどのファーストパーティ製ハーネス（Claude Code、Codex CLI、Gemini CLI）は自社モデルしかサポートしないため、この条件を満たさない
- カスタムエージェント同士が自律的に呼び出し合えること
複数モデルを使う必要性
- 特定のモデルは1人の人間のように見なせ、コンテキストを初期化しても同じ意見・強み・弱みを保つ傾向がある
- モデルに自分の書いたコードをレビューさせると自己同意に傾いてほとんど意味がないが、別のモデルにレビューさせると品質が大きく向上する
- 現時点ではCodex 5.4は細かくて厳密なのでレビューに向いており、Opus 4.6は自分が下す判断とよく一致し、Gemini 3 Flashも他モデルが見落とした解決策を示すことがある
- 最適な結果を得るには、すべてのモデルを混ぜて使うことが必要
ワークフロー: アーキテクト → 開発者 → レビュアー
- ワークフローはアーキテクト、開発者、1〜3人のレビュアーで構成され、これらはOpenCodeエージェント（スキルファイル）として設定されている
- 複数エージェントを使う理由は3つある:
- 高価なモデル（Opus）は計画立案に、安価なモデル（Sonnet）はコード記述に使い、トークンを節約する
- 異なるモデルでレビューすると、それぞれ異なる問題を捉えられる
- 役割ごとの権限分離ができる（例: 読み取り専用 vs 書き込み可能）
- 同じモデル・同じ権限で2つのエージェントを使っても、1人の人が別の帽子をかぶっているのと同じで、大きな意味はない
- スキルファイルは自分で手作業で書く。LLMにスキルを書かせるのは、誰かに「優れたエンジニアになる方法」を書かせて、その指示を返しながら「さあ優秀になれ」と言うようなものだ
アーキテクトの役割
- アーキテクト（現在はClaude Opus 4.6）は、唯一、直接会話するエージェントであり、最も強力なモデルであるべき
- 非常に具体的な機能やバグ修正の目標を提示し、目標・制約・トレードオフが固まるまで最大30分ほど会話する
- 成果物は、個別ファイルや関数レベルまで落とし込んだかなり低レベルの計画になる
- 単なるプロンプト入力ではなく、LLMの助けを借りて計画を形成するプロセスである。LLMが間違っていたり、自分のやり方と違ったりする場合は多くを修正し、それがプロジェクトを「自分のもの」にする中心的な貢献になる
- 明示的に「approved」という言葉を言うまでは実装を始めないように設定している。モデルによっては、自分で理解したと判断すると早まって実装に着手する傾向がある
- 承認後、アーキテクトが作業をタスクに分割し、計画ファイルに詳細を記録してから開発者を呼び出す
開発者の役割
- 開発者には、より弱くてもトークン効率の高いモデル（Sonnet 4.6）が使える
- 計画によって裁量の余地が最小限に抑えられているため、役割は厳格に計画の変更内容を実装することになる
- 実装完了後、レビュアーを呼び出す
レビュアーの役割
- 各レビュアーが独立して計画とdiffを確認し、批評する
- 最低でもCodexは常に使い、ときにGeminiを追加し、重要なプロジェクトではOpusも追加する
- フィードバックは開発者に戻り、レビュアー間で意見が食い違う場合はアーキテクトにエスカレーションする
- Opusは適切なフィードバックを選ぶのが得意で、厳しすぎる（実装に比べて実害の可能性が低い）フィードバックは無視することもある
全体的なアプローチと失敗モード
- この方法により、関数レベルを超えるすべての選択を把握し、その知識を後続作業に活用できる
- LLMがコードベース内の特定要素を見落とす盲点があるとき、「Yを使うべきだ」と指示すれば、LLMがYの存在を認識してより良い方法へ切り替えられる
- 技術に不慣れな場合、LLMの誤った判断を見抜けず、その上に誤った判断が積み重なって最終的に解けない状態に達する
- 「コードが動かない」と繰り返し指摘すると、LLMが「わかりました！直します」と言いながらかえってもっと壊してしまうのが典型的な失敗パターン
- そのため、特定の技術に詳しくなくても、計画段階でできるだけ多くを理解しようと努める
実際のセッション: Stavrobotにメール対応を追加
- 実際の注釈付きセッション全文を公開しており、ツール呼び出しや冗長な部分は省略しているが、会話と意思決定の流れはそのまま残している
- 初期の会話: 高レベルの目標を提示（「このボットにメール対応を追加したい」）→ LLMがコードを読み、現在のパターン（受信Webhook → enqueueMessage → LLM処理 → 応答）を把握した上で設計上の質問を提示
- 受信方式（IMAPポーリング、Webhook、SMTPサーバー）、送信方式、双方向対応の有無、アーキテクチャ（別コンテナ vs インプロセス）、HTMLメール処理、スレッド追跡、添付ファイルなど
- 設計決定: Cloudflare Email WorkerのWebhookで受信、SMTPクライアントで送信、完全な双方向会話、インプロセス処理、Markdown変換、独立したメールとして扱う、添付ファイル対応
- LLMによる詳細設計提案: MIME解析（
mailparserを使用）、Webhook認証（共有シークレット）、送信時の件名行の必要性、HTML専用メールの処理、Fromアドレスのアイデンティティ、転送メールの処理、送信添付ファイルなど、7つの懸念点と具体的な設計案を提示
- Workerのペイロードを
{ from, to, raw } に単純化し、サーバー側で解析する方式を提案
- Config構造、受信/送信フロー、修正ファイル一覧、明示的な非目標（YAGNI）の項目を整理
- 計画の精緻化: README.mdとconfig.example.tomlの更新、メール許可リストページでE.164検証を外すことなど、見落としを人間が指摘し、LLMが統合
- 6つのタスクに分割: Config/依存関係、許可リスト、許可リストUI/バックエンド検証、受信メール、送信メール、README/テスト
- 追加改善: SMTP設定がなくても受信メールだけは動作するよう、SMTPフィールドをオプションにするアイデアを提案し、実装
- QAで見つかったバグ: オーナーのメールが登録されておらずメッセージが破棄される問題 →
seedOwnerInterlocutor がメールチャネルを漏らしていたのが原因 → 修正
- コード改善提案: チャネルごとにハードコードされたifブロックではなく、共通チャネル一覧をループするようリファクタリング。Telegramの数値変換という特別ケースを議論した結果、
seedOwnerInterlocutor にのみループを適用し、getOwnerIdentities は型の違いが本質的であるため維持することに決定
- ワイルドカードメール許可リスト:
*@example.com 形式のドメインレベル・ワイルドカード対応を追加。使い捨てメールアドレスを使う実際のユースケースで必要だった
- セキュリティ上の考慮:
"me@mydomain.com"@evildomain.com のような攻撃を防ぐため、* を [^@]* に変換して**@の境界をまたげないように**処理
myusername+*@gmail.com のような部分ワイルドカードもサポート- 正規表現を使う際は、メールアドレス中の他のすべての文字をエスケープする必要があることを人間が指摘
- オーナーフィールドと許可リストの両方でワイルドカードが機能することを確認し、同じ
matchesEmailEntry ヘルパー関数を使用
- 機能全体の実装には約1時間かかった
エピローグ
- 極端に派手なセットアップではないが非常によく機能しており、プロセスの信頼性に満足している
- Stavrobotをほぼ1か月間24時間365日で運用しており、非常に安定している
10件のコメント
20年あまり前、Webエディタや量産型ブログの流行で誰にも見られないホームページや投稿が大量に生み出されたように、AI時代を迎えた今も似たような様相はあるが、カスタムアプリを作り、そのプロセスやルーティンを共有することは間違いなく素晴らしく大きな資産だと思う。個人的には、今の時代はAIで金になるアプリやサービスを作ることではなく、自分に必要なカスタムツールを手軽に作って生産性を高めることだと考えている。
実際、人間もそうだと思います。人間が多様性を追求すべき理由も、こういうことではないでしょうか……
言語モデルなので、高価なモデルが計画を立てるのが適切です。
> 高価なモデル（Opus）は計画立案に、安価なモデル（Sonnet）はコード作成に使ってトークンを節約
計画はSonnet、コード実装はOpusで行うことも多いようですが、ここは逆ですね
私は設計も
opusとcodexに掛け合いさせていますね。コーディングは
opusにやらせて、コードレビューは別のopusとcodexにやらせています。やっていて感じるのは、AIでも人でも他人の粗探しは本当にうまいな、ということです…
https://code.claude.com/docs/ko/model-config#opusplan-モデル設定
私もClaudeのopusplanでモデル設定して使っています
Oh my opencode の基本設定では、計画は opus が行い、実装はより軽量なモデルが担当します
私の周りでは、Sonnetで計画立案や設計をして、GLM-5でコードを書いているようです..
私も計画はSonnet、コード実装はOpusでやっていますが、筆者のやり方のほうがより効率的かもしれませんね。
私も Opus で計画し、レビューは Codex high、実際のコーディングは sonet や codex medium で回しています。