私のコーディングエージェントの使い方

はじめに

この記事は全て人間が書いています。
そしてこの記事には、当たり前すぎる内容しか書かれていないかもしれません。

はじめまして、@kenken38です。
普段は AI エンジニアとして、国内大手SIer にて AI 駆動開発や AI-Ready Engineering の推進に尽力しています。

この記事は、2026年7月時点での著者なりの AI コーディングツールの使い方をまとめたメモです。これまで様々な AI を（社内外を問わず）日常的に使ってきたことで蓄積された洞察擬きとノウハウ擬きを残したいと思います。

また最後には、Kiro（AWSが提供する AI コーディングツール）についても軽く触れています。

なお、本記事に書かれているのはコーディングエージェントの使い方の 「正解」 ではありません。記事の内容を単に真似すれば良い、という訳でもありません。

本記事が、より良いコーディングツールの使い方について皆さんと議論するためのきっかけになれば幸いです。

補足: 著者の AI 利用経験
Claude Code以外は個人利用です。

• Claude Code
  • 2ヶ月ほど前から業務で利用
• Codex
  • 課金あり（Plus）で1年ほど利用
• Cursor
  • 1ヶ月ほど無課金で利用
• Gemini
  • CLIは数回利用した程度。課金あり（Pro）
• GitHub Copilot
  • Pro+で年間契約していた。3年前(?)からメインで利用
• Kiro（課金: Pro+）
  • GitHub Copilotから乗り換えて、現在2ヶ月目

私のAIコーディングツールの使い方

まずは、どのAIコーディングツールかに依らない使い方を記載します。

Auto mode（完全自律モード）を使う

GitHub Copilotでは autopilotモードと呼ばれていますが、最初から最後まで人間による承認が不要なモードのことを指しています。

優れたLLMほど自律性が高く、結局人間の承認がボトルネックになっていたため、リスクの低い環境では出来るだけAuto modeを使うようにしています。

なお後述するように、Kiro v3では承認の要否を事前に細かく定義することが可能です。少なくとも、秘匿情報を含まないワークスペースへの読み取りなどであれば承認不要で良いと思います。

自分で作れないものをAIに作らせない

自分が理解していない技術や仕組みをAIに実装させない、と言った方が適切かもしれません。

「これからどのような実装が行われるのか」をある程度見通せる人間だけが、その実装をAIに任せる（しかもAuto modeで）ことが許されると思っています。

逆に自分では作れない・理解していないものをAIに作らせようとすると、バグが発生したときにトラブルシューティングのコストと難易度が跳ね上がるのは想像に難くないでしょう。

巷でいう「仕様駆動開発」も、ここで言っているようなAI成果物の見通しを立てるための手段なのかなと思います。
ただし私は、全ての実装仕様を事前に詳細化しておく必要はない、と考えています。（仕様駆動開発については後述）

もし人間がこれから作りたいものの実装方法や技術仕様を分かっていないときは、AI自身に技術的な解説資料（一次情報へのリンク付き）を作らせて、それにしっかり目を通すようにしています。

リンクを付けさせるのは、AIの成果物が正しいか否かを、人間側で判断しやすくなるからです。人間が、上司に説明するための資料を作るのと同じですね。

モデル選択を常に Auto にする

普段はモデル設定を Auto(LLMのモデルを自動で選択するモード) にしています。これは、少しでもクレジット消費を抑えたいからです。

なお Kiro CLI のモデルガイドによると、Auto は一般的な開発で推奨とされていますが、最も難しい開発では特定の高価格モデルの利用が推奨されています。

それでもやはり、私はケチケチ精神が働いて全ての開発作業で Auto を使っています。（ただし実際に Auto でどの程度節約できているのかは分かりません）

後述する仕様駆動開発が開発タスクを細分化し、開発の見通しを立てることでタスクの難易度を下げるのは間違いありません。このことが、私が Auto モードでも不自由なく開発できている理由なのかもしれません（タスクを丸投げしない、ということ）。

仕様策定の前に、AI にブレインストーミングさせる

仕様駆動開発では、まず最初に仕様を策定します。

しかし、いきなり仕様書を書き始める（AIに書かせ始める）人は少ないと思います。まずはブレストすべきです。このブレストをAIと人間が対話的に行うのではなく、(ほぼ100%)AIに任せてしまうというのが趣旨です。

一般にLLMは内部に確率的なメカニズムを採用しているため、発散的なタスクにも強みを持っているとされています。

ちなみに私は、以下のような簡単なプロンプトで AI にブレストさせています。

xxxについてブレインストーミングして
# temperatureを高く設定するための指示
ただし特定の最適解を得ることが目的ではなく、出来るだけ発散的に議論して
# ↓ の指示で本当に興味深い考察が得られることがある
ブレストする過程で、面白い気付きがあれば出力して

仕様駆動開発で作成する「仕様」は、必要最小限に留める

私は仕様駆動で開発を進めることが多いですが、どんなプロダクト開発であっても、プログラム詳細設計書のように「実装を先回りして書く」ということはしていません。

細かすぎる仕様は、人間のレビューや仕様作成が大きなボトルネックになってしまうからです。

そこで私は、最低限守ってほしい仕様だけを仕様書に書き起こします。こうすることで指示内容が抽象化され、長大な仕様書を書かずに済むようになります。

テストも必要最小限に絞る

AI コーディングツールを使った開発ではテスト駆動も品質を担保するための重要な方法です。

作らせようと思えば、AI はいくらでも詳細かつ膨大なテストを生成することが出来てしまいます。

しかし詳細なテストを作ることは、以下の理由からアンチパターンであると考えています。

• 保守性が下がる
• （現実的に）人間がレビュー出来なくなってしまう
  • 特に、ソースの改修内容が誤っている場合に、それに合わせる形でテストも直してしまうことがある

上述した仕様書作成の件と似たような理由から、テストコードも必要最低限だけ用意するのが良いのではと思います（その必要最低限を見極めるのが難しいのですが...）。

また後述する Kiro の実行権限を制御することで、テストコードは AI に修正させない（=人間が修正する）というのも、品質面を保証するために有効かもしれません。

私のKiroの使い方（願望）

続いて、Kiro 固有の話です。
これまで2か月弱 Kiro を使ってみた私が、「今後 Kiro をこう使いたい」と思っている内容について記載します。

私は Kiro を、 CLI v3（Early Access）で利用しています。

Kiro の実行権限を制御して、安心して使いたい

先述した通り、私は Kiro もAuto mode（完全自律モード）で実行してきました。

しかし Kiro CLI v3 では、新たに permissions.yaml という設定ファイルでエージェントの権限を設定することが出来るようになりました。（今まで出来なかったんかい！）

これによって、特定のワークスペース内だけで書き込みできるようにしたり、テストソースだけ変更させたりすることも可能となります。

ぜひKiroにも「最小権限の原則」して、安心安全な Kiro ライフを送りましょう！

テストコードと /goal で、無限バグ地獄を回避したい

AI コーディングツールを使っていると、発生したバグの根本原因を AI が特定できず、永遠にバグ解消できないでドツボに嵌る瞬間があると思います。

そのような悩みを、テストコードと /goal コマンドが解決してくれるのでは？と考えており、これを試してみたいと思っています。

/goal コマンドというのは、特定の目標に対して、それが達成されるまで処理をループする、というコマンドです。（ループエンジニアリングに近い考え方？）

この目標を「テストの通過」と定義することで、1回のコマンドでバグ解消まで自律的にやってくれるのではないかと夢見ています。

一方で、このようなドツボに嵌る事象には、AIが根本原因を正しく特定できていないことも起因しています。この問題は、例えば以下のような、また別の工夫が必要になることでしょう。

• /hook のような仕組みでプロダクトの仕様書を常に最新に保つ
• 信頼できる一次情報をMCPやWeb経由で取得する
• 「複数の仮説を立てて検証する」ようにAIの挙動を制御する
  • 「根本原因を特定しました（ウソ）」→「問題を修正しました（直っていない）」というパターンが多いため
    • このようなことを繰り返すと、おかしな修正が積み重なっていく
    • 1つの仮説に対して検証用ブランチを作り、上手くいかなかったら元のブランチに戻る、を徹底させるのも良いかもしれない

まとめ

いかがだったでしょうか。

共感する部分、しない部分それぞれあったと思います。是非コメントにて、皆さんのAIコーディングツールの使い方を教えてください。