はじめに
先日、Zennで「AIエージェント時代、正直しんどい話」という記事を読みました。
この記事では、AIエージェントを使った開発における認知負荷の問題が率直に語られています。要約すると以下のような課題です。
- 全ての成果物の承認が一人に集中する
- 「できました」とドカンと成果物を積まれる
- AIの「完璧です」が信用できない
- 知らないライブラリやパターンが使われるとレビューしきれない
- 分からないけど動くコードへの不安が消えない
これらの課題、実はプロンプトで軽減できる部分があります。本記事では、AIとの協働ルールをシステムプロンプトやカスタム指示に組み込む方法を紹介します。
問題の本質
元記事の指摘で特に重要なのは、人間の組織との対比です。
人間の組織では中間管理職がいて「任せる」ができます。信頼関係があるから、見なくていい範囲が生まれます。一方、AIエージェントは全ての成果物を人間が直接確認しなければなりません。
また、人間の部下なら「AとBどちらがいいですか？」と小出しに確認してきますが、AIは完成品をドカンと出してきます。確認が「会話」ではなく「レビュー業務」になってしまうのです。
これらの問題は、AIのデフォルトの振る舞いを変えることで、ある程度対処できます。
プロンプトで組み込む協働ルール
以下に、実際に使えるプロンプトの例を示します。
基本ルール（汎用）
## AIとの協働ルール
1. 完成品を一度に出さず、方針確認を優先してください。「できました」より先に「AとBどちらにしますか？」と聞いてください。
2. 「完璧です」「問題ありません」は使わないでください。代わりに、前提条件、想定外のケース、将来のメンテナンス上の懸念点を明示してください。
3. 私が「作って」と言っても、まず選択肢と判断基準を提示し、私が選んでから実装に移ってください。
4. 私が馴染みのないライブラリやパターンを使う場合は、事前に確認してください。
5. 「今動くか」だけでなく、仕様変更時の影響、メンテナンス性、担当者不在時のリスクについても言及してください。
開発プロジェクト向け（より具体的）
## 開発における協働ルール
### 実装前の確認
- 新しいファイルを作成する前に、ファイル構成案を提示して確認を取る
- 外部ライブラリを追加する前に、候補と選定理由を説明する
- 100行を超えるコードを書く前に、処理の流れを箇条書きで示す
### 実装時の姿勢
- 「完璧」「問題なし」という表現は禁止。代わりに制約や前提を明示する
- 知らないライブラリを使う場合は「○○を使いますが馴染みありますか？」と確認する
- エラーハンドリングの方針は実装前に相談する
### 成果物の提示
- 一度に全てを出さず、論理的な単位で分割して確認を取る
- コードを出す際は、変更の意図と影響範囲を先に説明する
- 「動きました」で終わらず、テストケースの網羅性や境界条件について言及する
### 長期視点
- このコードを1年後に別の人がメンテする前提で書く
- 仕様変更が入りそうな箇所は、その旨をコメントで残す
- 技術的負債になりそうな妥協点は、明示的に報告する
Claude向けのuserPreferences例
Claude.aiのuserPreferencesに設定する場合は、以下のような形式が使えます。
# 協働スタイル
- 完成品より方針確認を優先。「AとBどちらにしますか？」を先に聞く
- 「完璧です」は禁止。前提条件・想定外ケース・懸念点を必ず明示
- 馴染みのない技術を使う前に確認を取る
- 今動くかだけでなく、メンテナンス性と将来の変更リスクにも言及
# コード生成時
- 100行超のコードは事前に構成を相談
- 外部ライブラリ追加前に候補と理由を提示
- 成果物は論理単位で分割し、段階的に確認を取る
なぜこれが効くのか
これらのルールが効果的な理由は、AIの「親切心」を適切な方向に向けられるからです。
AIは基本的に「ユーザーの要望に応えたい」という方向で動きます。何も指示しなければ、「完成品を素早く出す」ことが親切だと判断します。しかし、「段階的に確認してほしい」と明示すれば、そちらの方向で親切にしようとします。
また、「完璧です」と言わないルールは、AIの過信を抑制する効果があります。AIは自信を持って回答する傾向がありますが、制約を明示するよう求めることで、より慎重な姿勢を引き出せます。
実践上の注意点
効果には限界がある
プロンプトで改善できるのは「AIの振る舞い」であり、根本的な問題は解決しません。
- レビューの認知負荷自体はなくならない
- AIが使う技術を全て理解する必要性は変わらない
- 最終責任は人間が負う構造は変わらない
あくまで「しんどさの軽減」であり、「しんどさの解消」ではありません。
モデルやツールによって効き方が違う
Claude、GPT、Geminiなど、モデルによってプロンプトへの反応は異なります。また、Claude CodeやCursorなどのツールでは、ツール側の設計思想が優先される場合もあります。
実際に試しながら、自分の環境に合わせて調整してください。
長すぎるプロンプトは逆効果
ルールを詰め込みすぎると、かえって守られなくなります。最初は3〜5個程度の核心的なルールから始めて、必要に応じて追加していくのがおすすめです。
まとめ
AIエージェントとの協働における「しんどさ」は、プロンプトで軽減できる部分があります。
核心は以下の3点です。
- 完成品より方針確認を優先させる
- 「完璧」を禁止し、制約と懸念点を明示させる
- 馴染みのない技術は事前確認させる
元記事の筆者が述べているように、AIを「メンターとして使う」という発想が重要です。「作って」ではなく「どうしたらいい？」と相談し、選択肢を出してもらって自分で選ぶ。この姿勢をプロンプトで強制することで、AIとの協働がもう少し楽になるかもしれません。
とはいえ、これは対症療法です。AIエージェント時代の認知負荷問題は、ツールや開発手法の進化によって本質的に解決されるべき課題でしょう。それまでの間、プロンプトという小さな工夫で、少しでも楽に開発を続けられればと思います。
追記：
いや、これ、記事をClaudeさんにプロンプト化できるか、できないかを聞いただけで、
「出来ます」と断言。
「じゃあ、ブログにしてね」で出てきた物です。Oups 4.5なのでSonnetより精度高いし、初期プロンプトである程度縛ってるから、ちょっといいかなと。信用しないで、実験してみてください。私も後で実験してみます。
ホントかよ？
コメント