Claude Code、プロンプトを磨くか出力を検収するか — 投資配分の意思決定論

「プロンプトを磨けば間違えない」は嘘

「もっといいプロンプトを書けば、AIは間違えなくなる」と思っていた時期が私にもあった。CLAUDE.mdを整備して、roleを明確にして、禁止事項を書き連ねれば、出力品質は安定するはずだと。

でも実際にblog-agentsを運用してみると、プロンプト側をどれだけ磨いても防げない問題が出てくる。たとえばHetzner CX11は、Claudeの学習データ上では実在する。でも2026年4月に廃止されたその事実は、どんなCLAUDE.mdにも書き込めない。学習データの古さはインプット側の問題ではなく、モデルの構造的な限界だ。

「プロンプトを完璧にすればAIは間違えない」という発想は、コンパイル時の型チェックだけあればランタイムテストは不要だと言っているのと同じくらい楽観的だ。

この記事では、Claude Codeへの投資を「インプット（入力設計）」と「アウトプット（出力検収）」の2つに分けて考え、どちらに先に投資すべきかの判断軸を整理する。

インプット投資とアウトプット検収の2極

Claude Codeを使って品質を上げる手段は、大きく2方向に分かれる。

インプット投資

インプット投資は、Claudeに渡す情報と指示の設計に手をかけることだ。

インプット投資の強みは「再現性」にある。一度書いた規約は次回以降のすべての実行に効く。

アウトプット検収

アウトプット検収は、Claudeが生成した結果を外から評価・修正する仕組みだ。

  • レビュアーエージェント（Auditor / Plagiarism / Tone-checker）
  • PostToolUse Hooksによる自動lint・format
  • Stop Hooksでのタスク完了時検証
  • 人間による最終承認

アウトプット検収の強みは「未知の問題を捕捉できること」にある。インプット側に書けない情報（廃止されたプラン、初出の誤りパターン）は、外からしか止められない。

両者は対立するものではなく相補関係にある。ただしリソースは有限なので「どちらに先に投資するか」は意思決定が必要になる。

blog-agents は 1Writer vs 4レビュアー構成

私が運用しているblog-agentsのパイプラインを見ると、インプットとアウトプットへの投資配分がそのまま設計に現れている。

Researcher → Auditor(リサーチレビュー) → Writer → Tone-checker → Plagiarism → Auditor(最終レビュー) → WordPress投稿

「書く」のはWriter 1人だが、「検収する」のはAuditor・Tone-checker・Plagiarism・最終Auditorの実質4ステージある。

これは最初からこの設計にしたわけではない。運用を重ねるうちに、アウトプット側を厚くしないと防げない問題が連続して見つかった結果だ。

具体的な事例をあげると:

  • ワークフローパターン記事の執筆時、PlagiarismエージェントがAgent Teams機能の「実験フラグ要件」の記載漏れを発見した。Writerは存在を知らなかったわけではなく、知識として持っていたが出力に落ちていなかった。
  • アンチパターン記事では、AMDのClaude Code日次コスト「$12→$1,504」という数値をPlagiarismが一次情報で裏取りできず削除した。数字自体は正確だったとしても、出典確認できない情報を公開することのリスクをインプット側では制御できない。
  • Hetzner CX11の廃止プランについては前述の通り。Writerに「廃止プランを使うな」とCLAUDE.mdに書いても、Writerは廃止されたことを知らない。

インプット側だけでは防げなかったものを、アウトプット検収が止めた。この非対称性がblog-agentsの設計に反映されている。

どちらか片方だけでは失敗する理由

インプット側だけに頼ると

プロンプト設計を極めようとするアプローチには、どうしても埋められない穴がある。

学習データの鮮度の問題は対処できない。Claudeが2024年時点で正しかった情報を返しても、それが2026年時点で正しいかはモデル自身には判断できない。

一度も指摘されていない癖は、Auto MemoryにもCLAUDE.mdにも入らない。その癖の「初出」を見つけるのはアウトプット検収側の仕事だ。

複数のSkillやサブエージェントが連鎖したときの挙動は、インプットだけでは予測不可能な組み合わせが生まれる。

アウトプット側だけに頼ると

反対に、インプット側を雑なままアウトプット検収だけを厚くしても機能しない。

インプット設計が甘いと、出力のばらつきが大きくなりすぎて検収コストが肥大化する。その場で修正できても、次回も同じ問題が出る。学習がインプット側に反映されなければ再現性は生まれない。

そして検収側は「全パターンを網羅する」ことはできない。インプット側で最低限の品質保証をしておかないと、検収の見落としが増える。

インプットは検収を効率化するための「下限保証」であり、検収はインプットでは防げないものを捕捉する「探知機」だ。どちらも必要で、どちらが欠けても機能しない。

投資配分を決める4軸

では具体的にどちらに先に投資するかは、どんな軸で考えればいいか。私が実際に使っている判断基準を整理しておく。

タスクのリピート性

記事執筆やコードレビューのように繰り返し実行するタスクは、インプット投資が複利で効く。CLAUDE.mdやknowledge/に書いた規約は、以降の全実行に適用される。

一方、PoC探索や初回調査のようにリピートしないタスクは、インプット側を磨く価値が薄い。そのぶんアウトプット側の人間レビューを厚くする。

失敗のコスト

本番デプロイやデータ移行は失敗コストが高い。このケースはアウトプット側を多段ゲートで固める。テスト・ステージング・人間承認の層を重ねる設計になる。

PoC段階や実験的な用途は失敗コストが低い。インプット側を軽く用意して動かし始め、問題が出てから追加する方が速い。

チームの成熟度

Claude Codeを導入したばかりのチームは、どんな問題が出るかがまだ見えていない。その状態でCLAUDE.mdを推測で太らせると、実態に合わない規約が積み上がりミスリードになる。

最初はアウトプット検収を厚くして、見つかったパターンをインプット側に還元していくのが現実的な順序だ。信頼度の考え方についてはこちらの記事も参照してほしい。

フィードバックループの成立

検収結果がインプット側に還元される設計になっているかどうかが、長期的な効率を決める。blog-agentsではPlagiarismやAuditorが指摘した内容をknowledge/ファイルに追記し、次回のWriter起動時に読まれる設計にしている。

このループが成立しているなら、インプットとアウトプット双方への投資が複利で効く。ループがなければ検収はその場限りになり、インプット側も改善されない。

還元サイクルと「2:8 → 4:6 → 6:4」の時系列配分

blog-agentsで採用しているのは「アウトプット検収 → インプット側に蓄積」という還元サイクルだ。

Writerが記事を出す → Auditor/Tone-checker/Plagiarismが検収して問題を指摘する → 指摘内容をknowledge/に追記する → 次回のWriter起動時に読まれる、という流れがある。この設計だと検収コストは時間とともに下がっていく。蓄積されたパターンが多いほどWriter側が事前回避できるからだ。

この経験から、私が今おすすめしている配分の目安はこうだ。導入直後はインプット20%・アウトプット80%。最低限のCLAUDE.mdと多段検収の組み合わせで始める。蓄積が進めばインプット側に反映できるようになり、1〜2ヶ月後にはおよそ40:60に動く。半年以上運用すると自動防御層が厚くなって、60:40という逆転が起きた。

最初に完璧なCLAUDE.mdを作ろうとしても、まだ見えていないパターンを推測で書くことになる。アウトプット側から始めるほうが、結果的にCLAUDE.mdの質も上がる。

まとめ

インプット投資とアウトプット検収は対立するものではない。ただ「先にどちらに重心を置くか」は、チームの状況とタスクの性質によって変わる。

blog-agentsの経験では、最初にアウトプット検収を厚くして「どんな問題が出るか」を観測することが、インプット側の設計精度を上げる近道だった。

とりあえず今使っているワークフローに1つレビューのステップを足してみるといい。それが将来のCLAUDE.mdやknowledge/に書くべき内容を教えてくれる。

コメント

タイトルとURLをコピーしました