ソフトウェアエージェンシーとの商談を始めると、開始から10分以内に必ずこのフレーズが出てくる。「AIを活用して開発を加速しています」。営業資料にも、ウェブサイトにも、すべての提案書にも書かれている。
問題はエージェンシーが嘘をついているわけではないことだ。ほとんどのエージェンシーは実際にAIツールを使用している。問題は「AIを使っています」という言葉が、そのエージェンシーが使わないエージェンシーよりも優れたソフトウェアを、より速く、より確実に構築できるかどうかについて、ほとんど何も教えてくれないことだ。
2026年には企業の57%がAIに特化したアウトソーシングパートナーシップを新たに形成している。市場はAIを期待している。しかし、クライアント側にはAI導入が実際に何を意味するのかを評価する明確なフレームワークがない——そしてエージェンシーはそれを知っている。
この記事では、そのフレームワークを提供する。
「AIを使っています」が何も語らない理由
2026年にAIを使っていると言うのは、コンピューターを使っていると言うのと同じだ。それは当然のことであり、差別化要因ではない。本当の問題は、AIがエンジニアリングプロセスにどう組み込まれているか——そしてそのプロセスがプロジェクトをより良くするのか、単に彼らのスタッフィングを安くするだけなのかということだ。
エージェンシーが開発業務にAIを統合する方法には、根本的に異なる2つがある。一方はあなたに利益をもたらす。もう一方はエージェンシーのマージンに利益をもたらし、あなたに隠れたコストを生み出す。
契約書に署名する前に、どちらを見ているのかを理解することが最も重要な評価作業だ。
エージェンシーのAI導入における2つのモデル
モデル1：シニアエンジニアの加速剤としてのAI
このモデルでは、経験豊富な開発者がAIツールを使って判断力を犠牲にせずに速く動く。シニアエンジニアはCopilotでボイラープレートを生成し、AIを活用したコードレビューでエッジケースを見つけ、ルーティン関数のテストカバレッジ生成にAIを使う。しかしシニアエンジニアは依然としてアーキテクチャを所有し、すべての生成出力をレビューし、すべての重要な技術的決定を行う。
ここでAIは力の乗数だ。エンジニアの判断が定数であり、出力は速く、品質はAIなしの場合と少なくとも同等——多くの場合それ以上だ。なぜなら、シニアの注意が反復作業ではなく複雑な問題に集中できるからだ。
モデル2：シニアエンジニアの代替としてのAI
このモデルでは、エージェンシーがAIツールを使ってシニアレベルの人員を削減する。ジュニア開発者やエンジニアでない人材がAIシステムにプロンプトを入力してコードを書かせ、表面的なレビューを経てリリースされる。エージェンシーは開発作業に請求するが、製品の中にある実際のエンジニアリング判断は薄い。
このモデルはエージェンシーのコストを劇的に削減する。見積もりは競争力があるように見える。しかし出荷されるコードは、設計が不十分で後から表面化する微妙なバグを含み、プロジェクト終了後も長期間にわたってメンテナンス問題を引き起こす。
皮肉なことに、どちらのモデルもピッチデッキでは同一に見える。
エージェンシーに聞くべき5つの質問
これらはひっかけ問題ではない。良いエージェンシーは明確に答えるはずだ。曖昧にしたりバズワードに転換するエージェンシーは、重要なことを示している。
1. エンジニアはどの段階でどのAIツールを使っていますか？
具体性を求めよう。GitHub Copilot、Cursor、Codeium、コード生成用Claudeなどのツールは実際の答えだ。「プロセス全体でAIを活用しています」は答えではない。ツールを挙げて特定のワークフロー段階に対応できないなら、AIを実践ではなくセールストークとして使っている。
2. AI生成コードはリリース前にどのようにレビューされますか？
すべての正規エンジニアリングチームにはレビュープロセスがある。誰がAI出力をレビューし、何を確認し、何がフラグを立てられるのかを知りたい。「AIがそれも処理します」という答えや、人間の判断が介在しない完全自動パイプラインを説明するなら、懸念を高めよう。
3. 典型的なプロジェクトにおけるシニアとジュニアエンジニアの比率は？
この質問は直接AIに関するものではないが、モデル1とモデル2を理解する最も速い方法だ。AIがシニア性のギャップを埋めるジュニア開発者が多いチームは、効率性の向上ではなくリスクプロファイルだ。
4. AIが役立ったプロジェクトの例を具体的に説明できますか？
具体的な例は良いサインだ。「ECクライアントのチェックアウトフローでAI生成テストカバレッジを使い、バグ検出率を落とさずにQA時間を30%削減した」のような実際のシナリオを説明できるなら、それは何をしているかわかっているチームだ。例が曖昧なままなら、能力も曖昧だ。
5. AIが関与する際の人間による監督体制はどのようなものですか？
これは責任に関する質問だ。AI生成コードが本番障害を引き起こした場合、何が起きるのか？誰が責任を持つか？どのように追跡されるか？成熟したチームには答えがある。AIを盾として利用するチームには回避策がある。
真のAIレディなワークフローとは
正しいアプローチを取っているエージェンシーにはいくつかの共通点がある。
彼らはAIツールの限界を理解するシニアエンジニアを持ち——AIが監視なしにできることとできないことについてのルールを設定している。AIはユーティリティ関数のユニットテストを書ける。AIはデータがシステムをどのように流れるかについてのアーキテクチャ決定はできない。その境界線は存在し、シニアエンジニアがそれを実施する。
彼らは低判断業務（ボイラープレート、ドキュメント草稿、初期テストスタブ）の時間削減にAIを使い、シニアの注意を高判断業務（アーキテクチャ、データモデリング、セキュリティ設計、パフォーマンス最適化）に集中させる。
コードがどのように書かれたかに関わらず、コードレビュー基準を維持する。AI生成コードは人間が書いたコードと同じ厳密さでレビューされる。なぜなら出力品質は変動し、人間とは異なる形でコンテキストに盲目だからだ。
責任に関する質問に明確に答えられる。何かが壊れたとき、どのエンジニアが所有しているかわかっている。AIはプロセスのツールであり、契約の当事者ではない。
時間の測定をやめて、成果を測定しよう
古いアウトソーシングモデルは時間と材料を中心に構築されていた——時間分の費用を払い、成果物はコード量だった。AIはそのモデルを壊しているが、多くのクライアントが予想する方向ではない。
変化はAIがコードを行単位で安くするということではない。AIを使う優れたエンジニアが、より少ない時間でより良い成果を提供できる——そしてそれが測定するものを変えるべきだということだ。
「何人の開発者で何時間」でエージェンシーを評価しているなら、AI以前の開発チーム向けに作られた指標を使っている。より良い指標はスプリントごとの成果だ：2週間のサイクルでどんな動作する機能が提供されるか、そして保守可能な方法で構築された適切な機能かどうか。
クリーンなアーキテクチャと確かなテストカバレッジで1スプリントに3機能を提供するエージェンシーは、1年かけて返済することになる技術的負債とともに6機能を提供するエージェンシーよりも価値がある。
AIは速い提供を可能にする。しかし、それがエンジニアリング判断と組み合わさったときだけだ。その組み合わせ——そしてそれを証明できる能力——が「AIレディ」の本当の意味だ。
TMNSolutionsのアプローチ
TMNSolutionsでは、AIツールはエンジニアの日常ワークフローの一部だ——シニア判断の代替としてではなく、その拡張として。どのツールを使うか、生成されたコードがどのようにレビューされるか、そしてすべてのプロジェクトで人間による監督がどこにあるかについて、明確にしている。
これはプロジェクトの見積もり、チーム構成、進捗報告の方法に組み込まれている。ベンダーを評価中であれば、私たちのプロセスを具体的に説明することを喜んでお伝えする——ツール、チーム構成、レビュー基準、そして責任についての考え方。
目標はAIであなたに感銘を与えることではない。目標は動作し、予定通りにリリースされ、ローンチ後も持続するソフトウェアを構築することだ。私たちのアプローチが、あなたが構築しているものに合っているなら、ぜひ話し合いましょう。
