株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
AIコーディングエージェントへの指示を改善する
Claude Code、Codex、Cursorなどのコーディングエージェントを活用するとき、「指示の仕方」は見直したい要素の一つです。成果はモデルの性能、作業の難しさ、環境、レビュー方法にも左右されるため、指示だけで一定の生産性向上が得られるとは限りません。
指示のやり取りを振り返る観点として、user_to_assistant_ratio(ユーザー発言数/AI発言数)があります。比較する際は、対象タスクや発言の数え方をそろえ、完了した成果物、正確さ、修正の手戻りも併せて確認します。比率の低さだけで、指示の上手さや生産性を判定することはできません。
本記事では、AIコーディングエージェントへの指示を見直すための7原則を、調査・成果物の指定・繰り返し作業の整理という観点から解説します。
原則1:「結果論じゃなくて事実ベースで調べて」——AIの安易な推測を排除する
AIエージェントへの指示で最も重要なのは、AIの表面的な回答を鵜呑みにしないことです。AIは「もっともらしい回答」を生成する能力に長けていますが、それは必ずしも「正確な回答」ではありません。
アンチパターン:AIの推測を受け入れる
環境変数が反映されない問題が発生したとき、AIが「設定ファイルを修正すれば解決します」と回答する。エンジニアがそのまま修正を指示する——しかし、これは根本原因に到達していません。
効果的な指示パターン
環境変数の問題を調べる際は、ビルド時と実行時にどの設定が読み込まれるか、上書きの順序はどうなっているか、該当コードと再現結果を確認するよう指示します。このように、推測と確認済みの事実を分ける調査を明示的に要求します。秘密の値そのものを応答やログへ出さずに確認できる方法を選びます。
設定ファイル管理ライブラリを使っている場合は、設定値の上書き順序やオプションの公式仕様も照合します。原因がアプリ、設定、ライブラリのどこにあるのかを切り分け、修正後は再現条件で確かめる手順です。
使えるフレーズ集
- 「結果論じゃなくて事実ベースで調べて」
- 「ブラックボックスにしないで」
- 「なぜその挙動になっているのか、根本原因を追及して」
- 「推測ではなく、コードを読んで確認して」
原則2:ゴールを最終成果物で指定する——中間成果物は要求しない
AIに対して「まず調査して」「次にまとめて」「それから実装して」と依頼する場合も、最終成果物と完了条件を先に示すと作業範囲を伝えやすくなります。段階的な調査・計画・実装は複雑な変更で有効な場合があり、一括指示の方が常に高品質という意味ではありません(公式:調査・計画・実装の進め方)。
非効率な指示
1. 「このコードベースの構造を調べて」 2. 「課題をリストアップして」 3. 「改善案を書いて」 4. 「実装して」
効果的な指示
「このコードベースの課題を調査し、見つかった課題を5カテゴリ (保守性・汎用性・責務分離・機能未実装・セキュリティ)に分類した 調査レポートを、依存関係マップ付きで作成して」
最終成果物の形式(カテゴリ数、分類軸、付録の有無)を明確にし、AIが調査→分析→整理→出力を進める際の基準にします。指摘件数は先に決めず、調査結果に応じて記載させます。必要な確認やレビューの段階も指定してください。
原則3:自分のワークフローをSkill化する
繰り返す作業手順をSkillとして定義すると、対応するコマンドから再利用できます。Claude Codeでは説明に応じた自動選択もあります。実行には必要なツール・権限・入力がそろっていることが前提です(公式:Skills)。
設計案:CIレビュー自動修正Skill
CI指摘への対応を整理するSkillでは、「対象の修正とチェックが完了したら終了」という条件を組み込みます。修正と再実行を繰り返す場合は、試行回数や費用の上限、同じ失敗が続く場合の停止条件も設けます。
CI指摘→修正→再実行→残った指摘の確認という手順をSkillにまとめると、反復作業を支援できます。権限が足りない操作や仕様判断が必要な場合は止め、チェックを通すためだけにテストや検証を弱めないことも条件にします。
設計案:コードレビューSkill
コードレビューSkillを、次の3フェーズに分ける方法を提案します。
- Phase 1:致命的な問題のチェック(場当たり的な実装、エラー握りつぶし、ハードコード、フォールバック処理)
- Phase 2:アーキテクチャ・設計のチェック(SOLID原則、DRY、クリーンアーキテクチャ)
- Phase 3:パフォーマンス・セキュリティのチェック(N+1問題、SQL injection、タイムアウト処理)
Skillにはプロジェクト固有ルールも必要に応じて加えます。例えば「共通処理は専用ユーティリティに集約されているか」「不要な後方互換処理を残していないか」など、チームの設計方針に合わせて確認項目を定めます。
Skill設計の原則
- 終了条件を明確にする:「修正対象ゼロ」「全チェック項目パス」など
- 思考設定を用途に合わせる:Claude Codeのultrathinkは、そのターンで深い推論を求める文脈上の指示を追加します。APIに送るeffort値を変更するものではなく、他製品共通の命令でもありません(公式:ultrathinkとeffort)
- 出力フォーマットを固定する:問題なし/改善推奨/要修正の3段階など
原則4:スクリーンショットでビジュアルフィードバックする
UIの調整は言葉だけでは伝わりにくいものです。「ボタンの位置をもう少し左に」「文字の色が見にくい」といったフィードバックは、スクリーンショットを貼りながら指示すると、対象箇所や意図を伝えやすくなります。
効果的なビジュアルフィードバックの手法
- 問題箇所を矢印で示す:「この部分」を特定してスクリーンショットに矢印を追加
- Before/Afterを比較:現状のスクリーンショットと理想イメージを並べて提示
- 画面全体ではなく該当箇所をトリミング:コンテキストを絞ることでAIの理解精度が向上
外部サービス連携の設定画面やUIの微調整でも、スクリーンショットに期待する状態を添える方法を検討できます。認証情報や非公開データが写っていないか確認し、画像だけで判断しにくい挙動は操作手順や実行結果も伝えます(公式:画像を使った作業)。
原則5:複数エージェントを戦略的に使い分ける
1つのAIエージェントだけを使うのではなく、タスクの性質に応じて複数のエージェントを使い分けることで、並列作業が可能になります。
使い分けの基準
| タスクの性質 | 検討するエージェントの例 | 選定時に確認する点 |
|---|---|---|
| 複雑な推論・対話 | Claude Code(Opus) | 必要な文脈を扱えるか、推論結果を検証できるか |
| 単純な実装タスク | Codex | バックグラウンドで進め、変更とテスト結果を確認できるか |
| 0→1の大規模実装 | Codex | 実装を分割し、依存関係と統合結果を確認できるか |
| ブラウザ操作を含む作業 | Claude Code | 利用環境で必要なブラウザ操作・権限に対応するか |
| バグ箇所特定済みの修正 | Codex | 再現手順と回帰テストで修正を確かめられるか |
並列実行の実践
独立した作業を複数のセッションに分けると、並列で進められます。効果は依存関係や統合作業によって変わるため、人数換算の効果を保証するものではありません。例えばCodexのデスクトップ環境ではLocalとWorktreeを使い分けられます。WorktreeはGitリポジトリで選択して使う仕組みで、全セッションが自動的に独立するわけではありません。変更範囲と統合担当を決めて運用します(公式:CodexのWorktree)。
原則6:MCP(Model Context Protocol)でコンテキストを最適化する
AIエージェントのコンテキストウィンドウは有限です。ツール定義や取得結果が使う量を確認し、不要な情報を減らします。Claude Codeには必要な時にツール定義を読み込むMCP tool searchがあり、サーバー数だけで負荷は判断できません。対応状況はモデルや接続先、設定によって異なります(公式:MCP tool search)。
モード切替パターン
業務ごとに必要な情報・ツールを整理する設計として、次の3つのモードを考えます。MCPの有効・無効はクライアントの管理機能と権限に従って設定し、Skillには利用するツールと作業手順を記載します。
- 日報モード:日次報告の作成に必要なMCPのみ有効化
- PMOモード:コア機能、課題管理、プロジェクト詳細のMCPを有効化
- コーディングモード:開発関連のMCPのみ有効化
日報作成のSkillには、必要な入力と利用するツール、出力形式を記載します。Skillを呼ぶだけでMCP接続設定が自動的に切り替わるとは限りません。Claude Codeでは/mcp等で接続状態を確認し、設定変更まで自動化する場合は対応する管理手段と権限を別途用意します(公式:MCPサーバーの管理)。
原則7:コンテキストウィンドウを管理する
コンテキストウィンドウには、現在のやり取りに使うメッセージ、読み取ったファイル、コマンド出力等が入ります。長い会話では圧縮・要約も行われるため、常に履歴全文をそのまま保持するわけではありません。情報量と残すべき要点を管理します(公式:コンテキストの管理)。
管理テクニック
- Claude Codeで別の作業へ移る際は
/clearを検討する:異なるタスクに切り替える際に会話履歴をリセット - 不要なファイル読み取りを避ける:必要な部分だけを指定して読み取る
- 必要な要点を残す:経過時間そのものではなく、情報量や圧縮・要約で重要な条件が抜けていないかを確認する
- サブエージェントで分離:セキュリティレビューなど独立した作業はサブエージェントに委任してコンテキストを分離
アンチパターン:避けるべき5つの指示方法
| アンチパターン | 問題 | 改善策 |
|---|---|---|
| 方針未確定で実装突入 | 手戻りが発生し、セッション時間が浪費される | 作業方針を先に策定し、合意を得てから実装開始 |
| AIの回答鵜呑み | 根本原因に到達できず、表面的な修正で終わる | 「なぜ?」を繰り返し、事実ベースの調査を要求 |
| セキュリティアラート放置 | .envアクセスやトークン露出リスクが蓄積 | CLAUDE.mdに方針を明記し、ツール・実行環境の権限とログも確認 |
| 同一ファイルの超高頻度修正 | 修正漏れ→追加修正のサイクルが発生 | 対象ファイルを事前にリスト化し、1セッションで完了 |
| 重要な条件を整理せず会話を継続 | 情報量や要約によって重要な前提が抜けるおそれ | 適切な粒度でセッションを区切る |
まとめ:指示の質を測る3つの指標
自分のAIエージェント活用レベルを測るには、以下の3つの指標を確認します。
| 指標 | 確認方法・運用目標の例 | 意味 |
|---|---|---|
| user_to_assistant_ratio | 同じ種類のタスクで比較 | 対話量を把握する補助指標。正確さや手戻りも併せて確認 |
| セッションあたり成果物数 | 1セッション = 1完了タスク | 完了条件を定め、必要なレビューや承認を経て完了 |
| カスタムSkill数 | 3つ以上 | 繰り返し作業がSkill化されている |
AIコーディングエージェントの真の価値は、「コードを書いてくれること」ではなく、「少ない指示で自律的に問題を解決してくれること」にあります。本記事で紹介した7つの原則を実践し、AIとの協働を次のレベルに引き上げてください。
関連記事:AIエージェント活用の完全ガイド
本記事は、AIエージェント活用シリーズの一部です。
- 入門:AIペアプログラミング入門|最初の1時間で覚える10コマンド
- セッション設計:AIコーディングセッション設計術|方針確定→実装の分離
- プロンプト管理:LLMプロンプトのバージョン管理実践ガイド
- セキュリティ:AIコーディングエージェントのセキュリティガバナンス設計
- ドキュメント:AI時代のドキュメント戦略|README・CLAUDE.md・AGENTS.md
AIエージェントの導入・活用でお悩みの方は、renueにご相談ください。




