私が実務でAIとどう付き合っているか（2025年版）

はじめに

前回の記事では、AIに「思考」までアウトソースしてしまった結果、結局すべてを自分で実装し直したという「痛烈な反省」を共有しました。

今も私はAIを使い続けています。
ただし、失敗を踏まえ、「AIに振り回される」のではなく、「AIを自分でコントロールする」ことを常に意識しています。

この一年、私はあらゆるツールを実務（あるいはその周辺）で試してきました。Devin、Cursor、Claude CodeやCodex。それ以外にもChatGPT、Gemini、NotebookLM、ManusやFeloなど、SNSで話題になっているものは一通り触ってきました。（他にもあった気がするけど）

この記事は、その壮大な試行錯誤の末にたどり着いた、現時点での私なりの『実務でのAIの取捨選択とハンドリング』の実践録です。

結論はシンプルです。何でもAIに任せない。任せる範囲・任せない範囲を自分で決める。速さよりも、集中を切らさない運用と、後から自分で説明できる実装を選ぶ、ただそれだけです。

幻想だった「並列開発」と「AIの全自動化」

前回の反省から、私は「AIに任せる領域」と「人間がやるべき領域」を分ける重要性を学びました。しかし、当初はまだ「AIの能力を最大化したい」という欲に囚われていました。

その結果が、2つの「失敗した試み」です。当時の私は「全部やる」を選んでいましたが、実務では「やらない」を選ぶことも立派な意思決定です。

失敗1： git worktreeによる「AI待ち時間」の有効活用

AIエージェントに複雑な実装を指示すると、どうしても数十秒〜数分の「待ち時間」が発生します。これが人間の集中力を切断することは、前回の記事でも書いた通りです。

私は考えました。「この待ち時間で、別のブランチの作業を進めれば最強なのでは？」と。

そこで git worktree（同じリポジトリで複数のブランチを同時にチェックアウトできる機能）を使い、AIにタスクAを指示している間に、人間はタスクBの開発に着手する、という「複数ブランチ同時開発」を試しました。

結果は、期待したほどの成果は得られませんでした。
私自身のコンテキストスイッチングコストが莫大すぎたのです。

タスクAの設計をAIに指示し、タスクBの修正を始め、集中してきたところでタスクAのアウトプットが返ってくる。そのレビューをしている間や途中MTGを挟むとタスクBの文脈は頭から抜け落ち、日をまたぐと「昨日、私はいったい何をしようとしていたんだっけ？」と両方のタスクの内容を忘れる始末。（私の脳内メモリが少なすぎるのかもしれませんが・・）

結局、git worktree は、本来の（？）使い方である「レビュー依頼後に、その待ち時間で次のタスクに取り掛かる」というシンプルな運用に落ち着きました。AIの待ち時間を埋めるための道具ではなかったのです。

失敗2： 複数モデル同時実行による「ガチャ」

次に試したのが、複数のAIを同時に走らせる手法です。
tmux を使い、複数ウィンドウでClaude Codeを同時に動かしました。

しかし、これも実務では使えませんでした。
理由は単純で、「ガチャ要素」が多すぎるからです。どちらも「それっぽい」が微妙に間違っているコードを生成してきた時、それを比較検討・マージするコストは、ゼロから自分で書くコストを遥かに上回りました。

さらに、一時期Claudeモデルが全体的に不調に陥った時期があったように、特定のAIサービスに依存しすぎる開発手法は、それ自体がリスクとなります。「AIに振り回される人間」になってしまう典型例でした。

「AIの速度」より「人間の集中力」

これらの失敗から、私は一つの結論に至りました。

実務でまず大事にしたいのは、「AIの計算リソース」ではなく、人間の集中力だと感じています。

AIの待ち時間でコンテキストスイッチを強いる git worktree も、AIのアウトプット比較で認知負荷を上げる「複数モデル同時実行」も、すべて人間の集中力を阻害します。

そこで、AIとの付き合い方で私が意識しているのは、次の二点です。

• AIの待ち時間を減らし、切り替え（コンテキストスイッチ）を生まない
• 無駄な生成をさせず、レビューと取捨選択のコストを最小化する

この思想に基づき、私は現在のワークフローを構築しました。だからこそ、プロンプトも出力も小さく刻み、私のレビューしやすさを最優先にするようにしました。

私の現在の実務ワークフロー

結論から言えば、私はAIを「思考のアウトソース先」ではなく、思考を終えた後の、超高速なタイピングマシーン兼ペアプログラマーとして扱っています。

具体的なツールとモデル選定

• エディタ： Cursor
  • もはやこれなしでは開発できません。IDEにAIが統合されていることのメリットが大きいからです。
• メインモデル： 直近(2025/11)では、CursorのComposer1 または GPT-4o
  • なぜ、Claude-4.5-SonnetやGPT-5ではなくGPT-4oなのか？
  • 答えは「高性能モデルはレスポンスが遅いから」です。
  • Composer1やGPT-4oは、爆速とはいかないまでも、人間が集中力を維持できるギリギリの速度で応答を返してくれます。大げさかもしれませんが、数秒の差が、一日の開発体験を大きく左右します。

具体的な開発手法：「超・解像度」指示

「AIの使い方が下手だ」と批判されるかもしれませんが、私はAIに「よしなにやって」とは決して言いません。

1. 前提：AIなしでも実装できる

   • これが大前提です。既存実装を完璧に理解し、実装の道筋とアウトプットが正確に頭の中にある状態でAIを使います。

2. 手法：人間が実装するのと同じ順序で、細かく指示する

   • AIに「ユーザー登録機能を実装して」とは言いません。
   • 一例ですが、「まず、user.controller.ts に createUser メソッドを追加して。ルーティングは POST /users で。DTOは CreateUserDto を使って」
   • 「次に、user.service.spec.ts に、正常系（パスワードをbcryptでハッシュ化して保存される）と異常系（重複メールなら DuplicateEmailError、DTO不正値ならバリデーションエラー）のテストを追加して、user.service.ts に create ロジックを実装。user.repository.ts の save を呼ぶ」
   • このように、人間が実装するのと全く同じ順序で、細かく実装イメージを伝えて、細かく実装させていきます。 抽象的な依頼を避け、差分で指示するのも取捨選択——余計な生成は捨て、必要な変更だけを選び取る姿勢です。

もしかしたら、このやり方は、AIの能力を最大限に引き出しているとは言えないかもしれません。
しかし、品質を重視するプロダクションコードや、思い入れのあるプロダクトに関しては、人間がすべての実装を把握し、ハンドリング下に置くことが必須だと考えます。

手を動かす（タイピングする）ことは減っても、それまでの過程で「どのファイルに」「どの順序で」「どんなコードを」書くべきか、人間が思考し、格闘し、プロダクトに向き合うプロセスは絶対に省略してはいけません。

AIモデルの「適材適所」

とはいえ、高性能モデルが不要なわけではありません。私は「実装フェーズ」と「調査フェーズ」でモデルを明確に使い分けています。基準は単純で、実装は「忠実さ」、調査は「読解力」。これに合わないと感じたら、ためらわず入れ替えます。

用途	重視すること	推奨モデル
実装	忠実さ・差分適用	Composer1, GPT-4o
調査	読解力・要約・仮説	Claude 4.5 Sonnet

• 実装フェーズ： Composer1, GPT-4o, GPT-4o-mini

  • 前述の通り、「速さ」と「指示への（比較的）忠実さ」を重視します。余計な実装をされるとレビューコストが上がるため、あえて「気が利かない」モデルを選ぶことすらあります。

• 調査・分析フェーズ： Claude 4.5 Sonnet

  • 調査フェーズでは最強の武器になります。
  • 「本番でこのエラーが出た。ログはこれ。考えられる原因を調査して」
  • 「（レガシーコードに対して）このリポジトリの決済処理について、何やってるか解説して。特にこのメソッドの依存関係をmermaidで出力して」
  • このようなタスクでは、Claude 4.5 Sonnet の深い読解力と推論力が、人間の調査時間を劇的に短縮してくれます。

おわりに： AIに振り回されず、AIを使いこなす

私がたどり着いた「細かく指示を出す」という地道なやり方。
これでも、2年前（AIエージェントの登場前）と比べれば、開発効率、特に「品質を担保した上でのスピード」については、圧倒的に上がっていると実感しています。（転職に伴う環境の変化もあり厳密な比較はできませんが、あくまで体感です）

SNSでは日々、新しい開発手法や、画期的なAIツールがバズっています。それらに飛びつくのも一つの経験です。

しかし、本当に必要なのは、それらの情報に振り回されることではなく、自分の開発スタイル、プロダクトのフェーズ、チームの文化に合わせて、「今、自分にとって本当に必要なツールは何か」を自分で考えて選ぶことだと思います。

人それぞれの開発スタイルがあるように、AIとの付き合い方にも人それぞれの「正解」があるはずです。
実務は取捨選択の連続です。AIも例外ではありません。
この記事も鵜呑みにせず、皆さんがご自身の「正解」を見つけるための一つの参考になれば嬉しいです。