SECTION 01
AI駆動開発で変わるのはコーディング速度ではなく、開発者の役割
AI駆動開発という言葉を聞くと、多くの人は「コードが速く書ける」という話を思い浮かべます。しかし本質的な変化はそこではありません。コーディングが速くなった瞬間に、本当のボトルネックが別の場所に移動するという構造的な変化が起きます。
40個以上のサービスをつくってきた経験から言えるのは、ボトルネックは常に移動するということです。コーディングが速くなったら、次は動作確認に時間がかかるようになります。それを潰したら、今度はインフラ周りの設定作業が詰まります。
この繰り返しの中で、気づいたら自分の役割が「実装する人」から「プロダクト全体を見る人」に変わっていました。AIが出てくる前の個人開発は、一人でやれる量しかつくれないという制約がありました。直列でしか進まなかったのです。
AIがコードを書く時代になって、この直列が並列に変わりました。自分は判断と方向修正に集中して、実装の大部分をAIに任せる。結果として、同時に複数のサービスを育てることが現実的になっています。
ここで意識しておきたいのは、AIが得意なのは真ん中の部分だけだということです。
- 最初の判断: 何を作るか決める、どんな体験を届けたいかを言語化する
- 真ん中の実装: AIが最も力を発揮する領域
- 最後の仕上げ: 動いてはいるけど「なんか違う」という違和感をつぶす作業
最初と最後は人間がやらないといけません。この最後の仕上げを「まあいいか」で流すか、ちゃんとやるかが完成度の差になります。
SECTION 02
まず何を使うか——CLI型とエディタ統合型の選び方
AIコーディングツールは大きく2つのタイプに分かれます。ターミナルで動くCLI型エージェント（Claude Code、Codex CLIなど）と、エディタに組み込まれた統合型（Cursor、Copilotなど）です。どちらが優れているという話ではなく、開発スタイルとの相性で選ぶのが正解です。
自分がClaude Code（Anthropic社が提供するCLI型AIコーディングエージェント）をメインに据えた理由は2つあります。複数のターミナルを同時に立ち上げて並行作業できること、そして長い文脈でもブレにくいことです。
CLI型とエディタ統合型の違いを整理すると、こうなります。
- CLI型: ターミナル中心の開発者向け。並列タスクや自動化との相性が良い
- エディタ統合型: コードを見ながら対話したい人向け。補完やインライン修正が直感的
- 併用: 大きな実装はCLI型、細かい修正はエディタ統合型という使い分けも有効
Gemini CLI（Google提供のCLI型AIツール）も試しましたが、複雑な問題の解決や継続的な開発作業では差が出る場面がありました。単発の質問には十分でも、プロジェクト全体を通して使い続けるとなると、文脈の保持力が効いてきます。
どちらを選ぶか迷っている人への判断軸はシンプルです。ターミナルに抵抗がなく、複数タスクを並行して回したいならCLI型を試してください。エディタから離れたくない、コードを見ながら少しずつ対話したいならエディタ統合型が合います。
SECTION 03
料金と従量課金で破綻しない運用ライン
AI駆動開発を始めるとき、料金体系の理解は避けて通れません。CLI型ツールでも、月額サブスクリプション、プラン同梱、APIの従量課金が混在しています。最初にどのプランを選ぶかで、心理的な安全性がまったく違ってきます。
自分はClaudeのMaxプラン（月額固定のサブスクリプション型プラン）を選んでいます。従量課金だと「使うたびにお金がかかる」という意識がブレーキになるからです。AI駆動開発は気軽に何度もAIに投げられることが前提なので、そのブレーキは致命的です。
従量課金と固定費プランの判断基準はこう考えています。
- 毎日使う人: 固定費プランのほうが精神的にも金額的にも安定する
- 週に数回だけ使う人: 従量課金でも問題ないが、上限設定は必須
- チームで導入する場合: まず一人が固定費プランで試し、効果を測ってから広げる
従量課金で怖いのは、想定外の長い会話や大きなコードベースの処理で一気に費用が跳ねるパターンです。APIの利用量ダッシュボードを毎日確認する習慣をつけるか、月の上限を設定しておくことを強くおすすめします。
個人開発や小規模チームが最初に選ぶなら、まず固定費プランで1ヶ月試すのが最も安全です。その1ヶ月で自分の使い方のパターンが見えてきます。そこから従量課金に切り替えたほうが得かどうかを判断しても遅くありません。
SECTION 04
設計フェーズをAI駆動に変える——計画書とモックアップの使い方
AI駆動開発で最も効果が大きいのは、実は設計フェーズです。コードを書く前の段階でAIを活用することで、実装中の手戻りが大幅に減ります。複雑な機能に入る前に、まずAIに計画書を作らせるのが基本の流れです。
計画書といっても大げさなものではありません。「この機能を実装するために必要なステップを洗い出して」と指示するだけです。AIが出してきた計画を見て、抜けている観点や順序の問題を人間が指摘する。このやりとりが、実装中の迷いを大きく減らします。
UI実装に関しては、モックアップが最強の仕様書になるというのが実感です。言葉で「こういう画面がほしい」と伝えるよりも、簡単なモックアップを先に作らせて「これをベースに実装して」と渡すほうが精度が段違いに上がります。
ここで重要なのが、AIへの聞き方です。「〜ですよね？」と確認を求めると、AIは忖度した答えを返しがちです。代わりに「この問題に対して考えられるアプローチを3つ挙げて、それぞれのトレードオフを説明して」のようなオープンクエスチョンで聞くと、本当に使える選択肢が出てきます。
設計フェーズでのAI活用で意識していることを整理します。
- 計画書を先に作らせる: 複雑な機能ほど効果が大きい
- モックアップを仕様書として使う: 言葉の曖昧さを排除できる
- 確認ではなくオープンクエスチョン: 忖度させず最適解を引き出す
- 自分の判断を最後に入れる: AIの提案をそのまま採用しない
SECTION 05
実装フェーズの回し方——並列タスクとレビューの実務
実装フェーズでは、複数のターミナルを立ち上げて並行作業するのが基本のワークフローです。たとえば、ターミナルAでフロントエンドの実装、ターミナルBでAPIの実装、ターミナルCでテストの追加を同時に進めます。これが直列だった開発を並列に変える具体的な方法です。
ただし並列作業を始めると、新たなボトルネックが動作確認に移動します。AIが実装したコードは「動くけど意図と違う」ということが起こりえます。複数のタスクが同時に完了すると、確認すべきものが一気に溜まります。
動作確認のボトルネックへの対処法はいくつかあります。
- タスクの粒度を小さくする: 一つのタスクを大きくしすぎない
- 完了順に即確認する: 溜めずにその場で見る
- AIにテストを書かせる: 動作確認の一部を自動化する
もう一つ実装中に意識しているのが、「やたら時間がかかっている」は黄信号だということです。AIがなかなか完了しない、何度もやり直しているような気配を感じたら、それはAIの理解がズレているサインです。そこで止めてリセットするほうが、結果的に速いです。
レビューについても触れておきます。AIが生成するコード量が増えると、レビュー負荷が確実に上がります。動くけど読みにくい、設計意図が伝わりにくいコードが出てくることがあります。ここは人間が見るしかない領域です。
レビュー負荷を下げるために、AIに「このコードの設計意図を説明して」と聞く習慣をつけています。実装直後に説明を出させることで、後からレビューするときの理解コストが大きく下がります。
SECTION 06
ボトルネックは移動する——潰し続ける姿勢が全て
AI駆動開発で繰り返し経験してきたのが、ボトルネックは解消するたびに次の場所に移動するという現象です。コーディングが速くなったら動作確認が詰まる。動作確認を効率化したら、今度は複数エージェントの管理が詰まる。この連鎖を受け入れることが大事です。
実際に体験した移動の流れはこうでした。
- 第1段階: コーディングが速くなり、動作確認がボトルネックに
- 第2段階: 動作確認を効率化し、インフラ設定がボトルネックに
- 第3段階: 複数AIエージェントの管理自体がボトルネックに
この第3段階のボトルネックを解消するために作ったのが、KingCoding（複数AIコーディングエージェントのタスク管理ツール）です。複数のターミナルで並列にタスクを進めると、何がどこまで進んでいるか把握するだけで頭を使います。そこを仕組みで解決したかったのです。
KingCoding自体をKingCodingで開発したというのが象徴的な事例です。開発期間は約2週間でした。AI駆動開発のボトルネックを、AI駆動開発で解消する。この循環が回り始めると、一気に加速感が変わります。
ここから得た教訓は、ボトルネックを見つけたら放置しないことです。「まあこんなものか」と慣れてしまうと、その非効率が日常に溶け込んでしまいます。違和感を感じたら、それは改善のサインです。
SECTION 07
社内コード・秘密情報を扱うときの安全な運用ライン
AI駆動開発を導入するとき、セキュリティの問題は必ず議論になります。特に社内コードや秘密情報を含むプロジェクトでは、どこまでAIに渡して良いのかを事前に決めておく必要があります。
CLI型ツールはローカルでファイル操作できる利点がありますが、実際にはプロンプトやコード断片がクラウドに送信されることもあります。データ保持や学習利用の扱いは、ツールと契約プランごとに確認が必要です。
クラウドにコードを送る場合に確認すべきポイントを整理します。
- 利用規約のデータ利用条項: 送信したコードが学習に使われるかどうか
- 組織のセキュリティポリシー: どのレベルの情報までAIに渡して良いか
- APIキーや認証情報の除外: .gitignoreと同様の除外設定をAIツール側にも適用する
やるべき最低限の設定としては、APIキーや環境変数をAIに渡さない設定を確実にしておくことです。ツールによっては、特定のファイルやディレクトリを除外する設定があります。これだけは初日にやっておいてください。
一方で、やりすぎないことも大切です。セキュリティを気にするあまり、コードのほとんどを渡さない設定にしてしまうと、AIの出力品質が著しく下がります。リスクの高い情報だけを確実に除外し、それ以外は渡すというバランスが実務的です。
SECTION 08
導入初日に効果を実感するための最初のタスク設計
AI駆動開発を始めるとき、最初のタスク選びが定着するかどうかを左右します。いきなり新規プロジェクトの開発に使うのは、実はおすすめしません。期待値が高すぎて、思い通りにいかなかったときに「使えない」と判断してしまうリスクがあるからです。
最短で効果を実感できるのは、既存コードベースへのリファクタリングやテスト追加です。すでにあるコードに対して「この関数にテストを書いて」「この処理をリファクタリングして」と指示すると、AIの実力がよく分かります。正解が分かっている状態でAIの出力を評価できるのがポイントです。
最初のタスクとしておすすめの順番はこうです。
- ステップ1: 既存コードのテスト追加やリファクタリング
- ステップ2: 小さな機能追加やバグ修正
- ステップ3: 新規機能の設計と実装
最初の成功体験が得られたら、少しずつ日常のワークフローに組み込んでいくのが自然な流れです。毎日のコーディングの中で「これはAIに任せられるな」と感じるタスクを一つずつ渡していきます。無理に全部をAI駆動に変える必要はありません。
大切なのは、AIを魔法のツールだと思わないことです。得意な領域では驚くほど力を発揮しますが、苦手な領域もあります。試行錯誤の中でその境界線を自分の感覚として掴んでいくことが、AI駆動開発を日常に定着させる最短ルートです。
