なぜあなたの「AIファースト」戦略は大きな間違いかもしれないのか？

この記事『Why Your”AI-First”Strategy Is Probably Wrong』（日本語訳は後述）を何度か目にしたが、少し異なる視点で語りたい。AIファーストというより、むしろソフトウェアエンジニアリング・ファーストだ。

この記事はAIについて語っているように見えるが、その実体はソフトウェアエンジニアリングの話である。

組織や人間に関する後半の議論はさておき、原文の前半部の要点を簡潔にまとめると以下のようになる。

AI時代において、人間のリソースがボトルネックとなる。プロダクトマネージャー（PM）が要件定義に数週間を要するのに対し、AIは2時間で実装してしまうため、PMがボトルネック化する。品質保証（QA）担当者が3日間かけてテストするのに対し、AIはコード生成に2時間しか要さないため、QAがボトルネック化する。チーム規模が25名であるのに対し、競合他社が数百名の人員を抱えている場合、人的リソースもまたボトルネックとなる。

ではどうするか？人間をそのプロセスから除外する。AIがコードを書き、AIがコードレビューを行い、AIがテストを実行し、AIがデプロイを行い、AIが本番環境の監視を行う。問題が発生すれば自動的にロールバックする。定期的にログをスキャンし、問題を自動検出・タスク割り当て・修正追跡を行う。このパイプラインを稼働させ、人間は重要な判断ポイントでのみ関与すればよい。

文中で言及されている統一コードベース（monorepo）は、花飾りに過ぎず、AIファーストとは直接関係ない。あっても良いが、なくても代替案は多数存在する。

この一連のソリューションを聞けば、論理は一貫しており、効果も魅力的だ。1日に複数回のデプロイが可能で、機能は当日公開・当日撤回でき、データが全てを決定する。

しかし、安易にこれをそのまま適用する前に、自社の状況と照らし合わせて以下の点を考慮すべきである。

第一に、自動化テスト。AIがコードを変更した後、他の機能を壊していないことを確認する方法が必要だ。テストカバレッジが不十分であれば、AIによるコード提出のたびに手動で回帰テストを行う必要があり、速度は向上しない。

第二に、CI/CD（継続的インテグレーション・継続的デリバリー）プロセス。コード提出からデプロイまでのテスト、レビュー、公開、ロールバックが完全に自動化されているか？このパイプラインが機能していなければ、AIがどれだけ高速にコードを書いても、手動処理を待つ間にコードが蓄積されるだけだ。

第三に、A/Bテストと本番環境の監視。新機能のリリース後、その効果はデータで検証可能であり、効果が得られなければいつでも停止できる仕組みが必要だ。このメカニズムがなければ、AIが1日に5つの機能を产出しても、どの機能を残し、どの機能を削除すべきか判断できない。

第四に、タスク管理。タスクは適切な粒度に分解され、ライフサイクルを追跡可能でなければならない。巨大で曖昧なタスクをAIに投げて、現在の能力では処理しきれない。複数のエージェントが同時に作業する場合、誰がどのタスクを担当するか、優先順位は何か、完了基準は何かなどを管理する仕組みが必要だ。

第五に、システムアーキテクチャ。アーキテクチャが混沌としている、あるいは存在しないコードをAIが保守するのは、人間と同じくらい頭痛の種となる。コンテキスト（文脈情報）が溢れていても境界線が見えず、一处を修正すると三処が破綻する状態では、AIも手が出ない。

これらの条件のうち、どれか一つでも満たせない場合、人間がそれを補完しなければならない。補完できない限り、「AIファースト」は単なるスローガンに過ぎない。

しかし、仮にこれら全てが満たされたとして、それでAIファーストが可能になるのか？

答えは否である。このアプローチが適用できるのは特定のシナリオに限られる。

適応可能なシナリオ：バックエンドロジックが中心で、ユーザーインターフェース（UI）が複雑でないプロダクト。例えばAPIサービス、データ処理プラットフォーム、社内ツールなどだ。機能の良し悪しは実行結果のデータで判断でき、画素単位の細かな確認を人間が行う必要はない。原文の例であるAgentプラットフォームは、本質的にバックエンド駆動型のプロダクトであり、このアプローチが適用可能である。

また、初期段階のプロダクトにおける迅速な試行錯誤にも適している。機能が失敗すれば即座に撤回でき、ユーザーの期待値もそれほど高くないため、AIの速度優位性を最大限に発揮できる。

UI集約型プロダクト。メディアでは「フロントエンドは死んだ」と頻繁に報じられるが、AIに複雑なインターフェースを作らせてみると、使いやすさの問題、インタラクションの細部、ビジュアルの再現性など、AIが解決できない課題が山ほどある。もしそれが可能なら、イーロン・マスクはすでにAIを使ってX（旧Twitter）を何十回も改版しているはずだ。

機能の品質が敏感なプロダクト。AnthropicやOpenAIが「AIファースト」を知らないはずがない。彼らがClaude CodeやCodexでこの手法を採用できるか？自社の中核プロダクトをAIに完全自動化された迭代（反復開発）を任せるなど、ユーザーから非難殺到するのは目に見えている。

安全性が求められるシナリオ。銀行システムやオンライン取引プラットフォームにおいて、AI が生成したコードにわずかなミスがあっても、単なるロールバックでは解決できません。

「AIファースト」の方向性自体は間違っていません。それは一種の意識の変革を表しています：意思決定を行うたびに、その作業をAIに任せることができるか考え、できない場合はどのような条件が不足しているのか、どうすればその条件を補完できるかを問う姿勢です。

しかし、この意識を実践に移すには、単にいくつかのAIツールのサブスクリプションを購入するだけでなく、基盤を構築する必要があります。テスト、CI/CD（継続的インテグレーション・継続的デリバリー）、モニタリング、アーキテクチャ、タスク管理といった要素を確実なものにすれば、AIの能力は自然と発揮されます。これらが不十分であれば、どれだけ多くのAIを追加しても、砂漠の上に建物を築くようなものです。

この観点から見ると、「AIファースト」の究極的な目標は、すべての作業をAIに任せることではありません。むしろ、この力を借りて、これまでやりたかったが推進力が不足していたエンジニアリングの改善を、実際に推進することにあります。

星空を見上げることは良いことです。しかし、同時に足元をしっかりと見据える必要があります。

なぜあなたの「AIファースト」戦略は間違っている可能性があるのか【翻訳】

著者：Peter Pang 原文：Why Your “AI-First” Strategy Is Probably Wrong

私たちの生産環境のコードの99%はAIによって作成されています。先週火曜日の午前10時、私たちは新機能をリリースし、正午にA/Bテストを実施しました。そして午後3時、データのパフォーマンスが芳しくないため、その機能を削除しました。午後5時には、最適化されたバージョンを再度リリースしています。3ヶ月前であれば、この一連のイテレーションサイクルには少なくとも6週間を要していました。

私たちがこれを実現できた理由は、コードエディタにCopilotプラグインをインストールしただけ那么简单ではありません。私たちは既存のエンジニアリング開発プロセスを根本から壊し、AIを中心に全面的に再構築しました。計画策定、コーディング、テスト、デプロイの方法、そしてチームの編成方法を変えました。さらには、社内すべての従業員の役割さえも再定義しました。

CREAOはAIエージェント（AI Agent）プラットフォームです。同社には25名の従業員がおり、そのうち10名がエンジニアです。私たちは2025年11月にエージェントの開発を開始し、ちょうど2ヶ月前にゼロからスタートし、製品アーキテクチャとエンジニアリングワークフローを完全に再編成しました。

OpenAIは2026年2月、私たちがこれまで行ってきたことを完璧に要約する新概念を発表しました。彼らはこれを「ハーネスエンジニアリング（Harness Engineering、注：Harnessの原義は馬具または安全ベルトですが、ソフトウェアエンジニアリングでは通常テストスタンドや足場を指し、ここではAIに作業環境と制約条件を提供するシステム工学を意味します）」と呼んでいます。エンジニアリングチームの主要な役割はもはやコードを書くことではなく、エージェントを強化し、価値ある作業を完了させることです。システムにエラーが発生した場合の解決策は、「再試行する」や「もっと努力する」ではありません。真の解決策は、AIがどの能力を欠いているのかを問い、その能力をエージェントにとって明確に可視化し、強制的に実行させる方法を見つけることです。

私たちはこの結論に独自に到達しましたが、当時はそれを定義する既存の用語がありませんでした。

「AIファースト」は「AIを使用すること」と等しくありません

多くの企業は、AIを既存のワークフローに無理やり組み込もうとしています。エンジニアはCursorを開いてコード作成を支援し、プロダクトマネージャーはChatGPTを使用して要件文書を作成し、QAチーム（テストチーム）はAIを用いてテストケースの生成を試みています。しかし、ワークフロー全体は昔ながらのままです。効率性が10%から20%向上したとしても、本質的な構造には何の変化もありません。

これはせいぜい「AIアシスト（AI-assisted）」と呼べる程度です。

真の「AIファースト」とは、「AIが主要な構築者である」という核心仮定に基づき、プロセス、アーキテクチャ、組織を徹底的に再設計することを意味します。「AIがエンジニアをどう支援できるか」ではなく、「AIに構築作業を行わせ、エンジニアは方向性と品質の判断のみを担当するよう、すべてをどのように再構築するか」を問うべきです。

この2つのアプローチがもたらす差は指数関数的です。

私は、「AIファースト」と称する多くのチームが、依然として従来のアジャイルスプリントサイクルを回し、同じJiraタスクボードを使用し、毎週のスタンドアップミーティングを開き、同じQA（品質保証）の承認プロセスを経ているのを見てきました。彼らは単にAIを既存のサイクルに無理やり組み込んでいるだけで、そのサイクル自体を再設計していません。

この現象の典型的な例が、現在よく言われる「ヴィーブコーディング（Vibe Coding）」です。Cursorを開き、コードが動作するまでプロンプトを調整し、コミットし、それを繰り返します。この手法はプロトタイプ検証には適していますが、本番環境で使用するシステムは安定性、信頼性、安全性が必須です。AIにコードを書かせるときには、これらの特性を保証し、バックアップできるシステムを構築する必要があります。あなたが構築すべきは「システム」であり、プロンプトは使い捨てのものであるべきです。

昨年、私はチームの作業方法を注意深く観察し、私たちの命を危うくする3つのボトルネックを発見しました。

私たちのプロダクトマネージャーは過去、機能の調査、設計、詳細な計画立案に数週間を要していました。数十年間、プロダクトマネジメントはこのように機能してきました。しかし、AIエージェントが1つの機能を実装するにはわずか2時間しかかかりません。開発期間が数ヶ月から数時間に極端に圧縮された場合、その長い数週間の計画サイクルが最大の足かせとなります。

数ヶ月かけてアイデアを練り、わずか2時間でそれを実装するというのは非論理的です。

プロダクトマネージャーは、迅速な反復サイクルで作業できる「プロダクト思考を持つアーキテクト」に進化するか、開発プロセスから退出するかの二者択一です。プロダクトの設計は、長文の要件ドキュメントを委員会が審査するのではなく、「高速プロトタイピング - リリース - テスト - 反復」のサイクルを通じて行わなければなりません。

状況は同様です。AIエージェントが2時間で機能をリリースした後、QAチームはさまざまなエッジケースや極端なケースのテストに数日を要します。開発2時間、テスト3日。

そこで、私たちは手動QAに代わってAI構築された自動化テストプラットフォームを導入し、AIが書いたコードをAIでテストする仕組みを作りました。検証の速度は開発の速度に追いつかなければなりません。そうでなければ、あなたは古いボトルネックから10フィート離れた場所に、新しいボトルネックを構築しているに過ぎません。

私たちの競合他社は同じ作業を100倍、あるいはそれ以上の人数で実施していますが、私たちはわずか25名です。無秩序な採用で彼らに追いつくことは不可能であり、「再設計」によってのみ切り開くことができます。

私たちは、プロダクトの設計方法、実装方法、テスト方法という3つのシステムにAIを深く統合する必要があります。いずれかの環節が純粋な人手に依存している場合、それが全体の生産ラインを遅延させます。

過去、私たちのアーキテクチャは複数の独立したシステムに散在していました。1つの機能を変更するために、3つから4つのコードリポジトリを同時に修正する必要がありました。人間のエンジニアから見れば、これはどうにか対応可能でした。しかし、AIエージェントの視点からは、それはブラックボックスに過ぎません。エージェントは全体像を把握できず、サービス横断的な連鎖反応を推論することも、ローカルでインテグレーションテストを実行することもできません。

私はすべてのコードをモノレポ（Monorepo）に統合せざるを得ませんでした。理由はただ一つ：AIが全体を俯瞰できるようにするためです。

これが、スキャフォールディング（Scaffolding：足場）の概念を実践で応用したものです。システムのより多くの部分を、AIが検査・検証・修正可能な形式に変換すればするほど、得られるレバレッジ（効果の増幅）は大きくなります。フラグメント化されたコードベースはAIにとって見えない存在ですが、統一されたコードベースはそれらにとって明確で読みやすいものとなります。

私は新システムの設計に1週間を費やしました：計画フェーズ、実装フェーズ、テストフェーズ、統合テストフェーズ。その後、さらに1週間をかけ、エージェント（Agent：自律的にタスクを実行するソフトウェア）の支援を受けてコードベース全体のリファクタリングを行いました。

CREAO自体がエージェントプラットフォームです。私たちは自社のエージェントを用いて、エージェントを動作させるプラットフォームを再構築しました。もし製品が自らを構築できるのであれば、その道筋は通っているということです。

以下は私たちの技術スタックと、各モジュールの役割です。

基盤インフラ：AWS（Amazon Web Services）

私たちはAWS上で稼働しており、自動スケーリングコンテナサービスとサーキットブレーカー（Circuit Breaker：障害発生時に処理を遮断しシステム全体への影響を防ぐパターン）およびロールバックメカニズムを使用しています。デプロイ後に監視指標が悪化した場合、システムは自動的に前の安全なバージョンにロールバックします。

CloudWatchはシステムの中枢神経です。すべてのサービスには構造化されたログがあり、25以上の自動アラートが設定され、自動化されたワークフローがカスタム指標を毎日クエリしています。すべてのインフラストラクチャコンポーネントは、構造化されクエリ可能なシグナルを公開しています。（注：構造化ログとは機械が読み取りやすいよう統一フォーマットで記録されたログ；クエリ可能なシグナルとはAIが直接検索できる重要な運用データ）もしAIがログを読めなければ、問題を診断することはできません。

CI/CD：GitHub Actions

すべてのコード変更は、執拗な6段階パイプラインを通ります：

検証CI → 開発環境へのビルドおよびデプロイ → 開発環境のテスト → 本番環境へのデプロイ → 本番環境のテスト → 正式リリース

すべてのプルリクエスト（Pull Request、略称PR：コード変更を反映させるための要求）には、ガバナンスメカニズムが適用され、型チェック、コードスタイルチェック、ユニットテストおよび統合テスト、Dockerビルド、Playwrightによるエンドツーエンドテスト、環境一貫性チェックが強制されます。どのフェーズもスキップすることはできません。人工的な強制的な承認（人工グリーンライト）は許可されません。パイプライン全体が絶対的に確定的であるため、AIは結果を予測し、失敗の原因を推論することができます。

すべてのPRに対して、Claude Opus 4.6による3つの並列AIレビューがトリガーされます：

コード品質：論理エラー、パフォーマンス問題、保守性の確認。

セキュリティ：脆弱性スキャン、認証境界チェック、インジェクション攻撃リスクの調査。

依存関係スキャン：サプライチェーンリスク、バージョン競合、オープンソースライセンスの問題。

これらは単なる提案ではなく、通過必須のゲートです。これらは人間のレビューと並行して動作し、人間が見落としがちなエラーを一括でブロックします。1日に8回のデプロイを行う場合、どの人間のエンジニアもすべてのPRに高い集中力を維持することはできません。

エンジニアは、任意のGitHub IssueやPRで @claude をメンションすることができます。

毎朝（UTC 9:00）、自動化されたヘルスチェックワークフローが正確に起動します。Claude Sonnet 4.6はCloudWatchをクエリし、すべてのサービスのエラーパターンを分析し、システムヘルスの実行サマリーを生成してチームのチャットグループに送信します。これには、誰かが明示的に指示する必要はありません。

1時間後、トリアージエンジンが起動します。これは本番環境のエラー情報を分類クラスタリングし、9つの次元から各問題の重大度を評価し、タスク管理システム内に調査チケットを自動生成します。すべてのチケットには、ログサンプル、影響を受けたユーザー、影響を受けたAPIエンドポイント、および推奨されるトラブルシューティングの方向性が添付されています。

システムは自動重複排除も行います。既存のチケットが同種のエラーをカバーしている場合、そのチケットを更新します。以前に解決された問題が再発した場合、回帰（Regression：修正したはずのバグが再び発生すること）を鋭敏に検出し、チケットを再オープンします。

エンジニアが修正コードを提出すると、同じパイプラインがすべての処理を引き受けます。Claude が3回のレビューを行い、CI（継続的インテグレーション）が検証を行います。6段階のデプロイメントパイプラインによって各環境へ展開され、テストが実施されます。デプロイ完了後、トリアージエンジンが再度モニタリングデータを確認します。もし元のエラーが解決していれば、チケットは自動的にクローズされます。

各ツールは特定のフェーズのみを担当し、どのツールもすべてを一手に引き受こうとはしません。この日常的なサイクルにより、「自己修復ループ」が形成され、最小限の人的介入でエラーの検出、トリアージ（選別・優先順位付け）、修正、検証が行われます。

私は『ビジネスインサイダー』の記者に対し、「AI がコードの作成と提出を担当し、人間は戦略的なリスクの有無を審査するだけだ」と語りました。

機能フラグ（Feature Flags、注：コード内で機能の有効・無効を制御する技術。再デプロイなしでいつでも機能をオンオフ可能）の管理には Statsig を使用しています。すべての新機能は、リリース前に機能フラグの背後に隠されています。公開プロセスは非常に堅牢です：まずチーム内部向けに開放し、次にパーセンテージベースのグラデーションリリース（段階的公開）を行い、最後に全面開放するか、あるいは完全に削除します。「ワンクリック停止」機能により、再デプロイすることなく瞬時に機能を無効化できます。もしある機能がデータ指標を悪化させた場合、数時間以内に撤回されます。品質の低い機能は公開当日に「死滅」します。A/B テストも同じシステム上で実行されます。

Graphite はコードブランチの管理を担当します：マージキューは検証を再実行し、すべてのチェックが合格した場合のみメインブランチへのマージを許可します。これにより、高頻度なコード提出と体系的なレビューを両立できます。

Sentry はすべてのサービスの構造化された例外を報告し、トリアージエンジンがそれをモニタリングデータと組み合せます。Linear は人間向けのインターフェースであり、重大度スコアと調査提案を含むチケットを自動作成し、その後の検証が完了すると自動的にクローズします。

機能のアイデアから本番環境への移行プロセス

アーキテクトは、コードベースのコンテキスト、目標、制約条件を含む構造化プロンプトとしてタスクを定義します。

エージェントはタスクを分解し、実装計画を立て、コードを作成し、関連するテストを自動生成します。

PR（プルリクエスト）を開きます。Claude が3回のレビューを行います。人間のレビュアーは、行ごとの細部ではなく、高次元のリスクのみをチェックします。

パイプラインによる検証：型チェック、コードスタイルチェック、ユニットテスト、インテグレーションテスト、エンドツーエンドテスト。

6段階のデプロイメントパイプラインにより異なる環境へ展開され、各フェーズでテストが実施されます。

チーム内部向けに機能フラグを有効化します。段階的に公開し、データ指標を注視します。

データが悪化すればいつでもワンクリックで停止できます。重大な問題が発生すると自動でサーキットブレーカーが作動し、ロールバックされます。

Claude トリアージエンジンが重大度を評価し、完全な調査コンテキストを含むチケットを自動作成します。

エンジニアが調査に介入します。この時点で AI はすでに診断作業を完了しています。エンジニアは結論を検証し、修正コードを提出するだけです。

厳格なコードレビュー、検証、デプロイメント、モニタリングのパイプラインを同じものを使用します。

トリアージエンジンが再検証を行います。解決が確認されれば、チケットは自動的にクローズされます。

この2つのパスは完全に同一のパイプラインを使用しています。同じシステム、同じ基準です。

過去14日間、私たちは平均して毎日3〜8回の本番環境へのデプロイを行ってきました。旧モードでは、この2週間で1回のリリースも実施できませんでした。

機能が劣悪であれば、リリース当日に削除される。新機能は考案されたその日に公開できる。A/B テストによってビジネスへの影響をリアルタイムで検証する。

多くの人は、私たちが速度と品質のトレードオフを取っていると考えている。しかし逆だ。ユーザーエンゲージメントが上昇し、コンバージョンレートも向上した。私たちは以前よりも優れた製品を作っている。フィードバックループが極めて短くなったからだ。毎日リリースして得られる学びは、月1回のリリースよりも圧倒的に多い。

未来には、エンジニアは2つのタイプしか存在しない。

たった1〜2人のアーキテクトだ。彼らは標準作業手順（Standard Operating Procedure: SOP）を設計し、AIの動作原理を教える。テストスタブ（Stub）、統合システム、トリアージネットワーク（Triage Network）を構築する。システムアーキテクチャと境界条件を決定し、エージェントにとって「良い」とは何かを定義する。

この役割には極めて深い批判的思考力が求められる。やるべきことはAIに従うことではなく、AIの欠点を指摘することだ。エージェントが提案を出した際、アーキテクトは抜け漏れを見逃さず、問題点を鋭く見つけなければならない。どの失敗モード（Failure Mode）を見落としているか？ 安全境界を越えていないか？ どのようなテクニカルデット（Technical Debt）が蓄積されているのか？

私は物理学の博士号を持っている。博士課程で学んだ最も有用なことは、仮定を疑い、論理にストレステストを行い、論理的欠陥を探す方法だった。未来において、AIを批判する能力は、コードを書く能力よりも価値を持つだろう。

残りの全員。仕事は依然として重要だが、構造が変わった。

現在はAIが人間にタスクを割り当てる。トリアージシステム（Triage System）がバグを検出し、チケットを作成し、診断結果を示して適切な担当者に割り当てる。人間は調査、検証を行い、修正案を承認する。AIがコードを提出し、人間がリスク審査を行う。

これらの仕事には依然として高いスキルと集中力が必要だが、旧来のようなゼロからシステムアーキテクチャを構築する推論能力はもはや必要とされない。

私は予想外の現象を観察した。ジュニアエンジニアがシニアエンジニアよりも早く適応していることだ。

従来の思考パターンに縛られていないジュニアエンジニアにとって、これは虎に翼を得たようなものだ。彼らは自身の影響力を無限に増幅できるツールを習得しており、破棄すべき何十年もの古い習慣がない。

一方、豊富な伝統的経験を持つシニアエンジニアは、最も苦しい葛藤を経験している。以前であれば2ヶ月かかった作業が、今ではAIが1時間で完了してしまう。何年もかけて希少なスキルを磨いてきた人々にとって、これは耐え難い打撃である。

正誤を判断しているわけではなく、私が目にした現実を述べているに過ぎない。この変革において、蓄積された過去のスキルよりも適応能力の方が重要である。

2ヶ月前、私は時間の60%を人員管理に費やしていた。優先事項の調整、会議、フィードバック提供、エンジニアへのコーチングだ。

従来のCTO（Chief Technology Officer）のモデルは、チームにアーキテクチャを任せてエンパワーし、トレーニングを行い、業務を引き渡すよう教えている。しかし、このシステムに1〜2人のアーキテクトしか必要ないのであれば、私はまず自ら手を動かして構築しなければならない。「マネージャー」から「ビルダー（構築者）」に戻ったのだ。現在、私は朝9時から深夜3時まで毎日コードを書いている。システムの基盤ロジックとアーキテクチャを設計し、インフラストラクチャのスタブ（Stub）を維持している。

プレッシャーは増したが、人々と「アライン（調整）」する日々よりも、純粋な「ビルド」の楽しさの方が好きだ。

創業者およびエンジニアたちとの関係は、以前よりも良くなった。

移行前、チームとの大半のやり取りは会議で行われていた。技術的なトレードオフの議論、優先順位をめぐる争い、技術的意思決定を巡る激しい論争。従来のモデルではこれらの対話は必要不可欠だったが、極めて心労を伴うものでもあった。

今も私はチームとコミュニケーションを取る。仕事以外の話題で雑談したり、リラックスするためにチームビルディング（Team Building）を行ったりする。私たちはより良好な関係で過ごしている。なぜなら、今ではシステムに任せることができるような作業について争う必要がなくなったからだ。

私が毎日業務のコミュニケーションを取らなくなると、一部のチームメンバーは不安を感じた。CTOが話しかけてこないのはどういう意味か？ 新しい世界において、自分の価値はどこにあるのか？ これらの懸念はすべて妥当である。

一部の人は、「AIが自分の仕事を奪えるかどうか」をチャットで議論することに、実際の作業に費やす時間よりも多くの時間を割いている。移行期には不安が避けられない。それに対する完璧な慰め言葉など、私にもない。

しかし、私には一つの原則があります。エンジニアがオンライン上でバグを書き込んだからといって、彼を解雇することはありません。私たちは審査プロセスを改善し、テストを強化し、ガードレールを追加します。AI に対しても同様です。もし AI が誤りを犯したなら、より良い検証メカニズム、明確な制約条件、そして強力なシステム観測性（System Observability）を構築すればよいのです。

私は、一部の企業がエンジニアリング開発において「AI 優先」を採用している一方で、他の部門は依然として手作業に頼っているのを目にします。

もしエンジニアが数時間で機能リリースができるのに、マーケティング部門がアナウンスを出すのに一週間もかかるなら、マーケティング部門が新たなボトルネックとなります。もしプロダクトチームがまだ「月」単位で計画を立てているなら、製品企画（Product Planning）がボトルネックです。

CREAO では、AI 原生の運用方式をすべての機能部門に展開しています：

プロダクト更新ノート：コード変更履歴と機能説明に基づき AI が自動生成。

機能紹介動画：AI による動的デモの自動生成。

ソーシャルメディアの日常投稿：AI による企画と自動投稿。

ヘルスレポートとデータ分析：監視および本番環境のデータベースから AI が抽出・生成。

エンジニアリング、プロダクト、マーケティング、ユーザー成長のすべてが、同じ「AI 原生」のワークフローの中で稼働しています。もしある部門がエージェント（Agent）の光速で動き、別の部門が人間の亀の速さで爬行しているなら、人間の速度が会社全体の足を引っ張ることになります。

あなたのコアバリューは、「コードを書く生産量」から「意思決定の質」へと移行しています。コードを素早く記述する能力は、毎月価値が下落しています。一方、AI を評価し、批判し、指導する能力は急速に価値を上昇させています。

プロダクトへの鋭い感覚と品味が極めて重要です。AI が生成した UI 画面を一目見ただけで、ユーザーが不平を言う前に直感的に「何かおかしい」と気づけますか？アーキテクチャの提案書を一目見ただけで、AI が見落としたシステム上のリスクを瞬時に看破できますか？

私はいつも 19 歳のインターン生にこう伝えています。批判的思考を意図的に練習しなさい。論拠を評価する方法、論理的な抜け穴を探す方法、当たり前の仮定に疑問を呈する方法を学びなさい。良いデザインとは何かを学びなさい。これらのスキルは複利効果を持っています。

もし製品企画に要する時間が、コード実装に要する時間よりも長いなら、そこからすぐに手を付けなければなりません。

大規模な AI エージェントの導入に先立ち、テストのためのインフラ（Testing Scaffold）を整備してください。高速な検証を裏付けとして持たない高速 AI は、急速に蓄積する技術的災害をもたらすだけです。

アーキテクトから始めましょう。このシステムを構築し、その有効性を証明できる人物を見つけてください。システムが稼働したら、他の人員を「オペレーター」の役割に配置します。

「AI 原生」を各機能部門へ強制的に展開してください。

抵抗と反対が必ず発生することを覚悟してください。

OpenAI、Anthropic、そして多くの独立チームは、同じ原則へと収束しつつあります：構造化されたコンテキスト、専門化されたエージェント、永続的なメモリ（Persistent Memory）、そして実行の閉ループです。インフラ整備は業界標準になりつつあります。

これらを駆動するエンジンは、モデル能力の進化です。CREAO で最近起きたすべての質的変化は、過去 2 か月間に帰属できます。Claude Opus 4.5 ではできなかったことが、Opus 4.6 では可能になりました。次世代のモデルは、この変革をさらに激しくするでしょう。

私は、「一人会社」が非常に一般的になるだろうと信じています。もしアーキテクトが一連のエージェントを率いて 100 人の仕事ができるなら、多くの会社は第二名の従業員を採用する必要すらありません。

私が接したほとんどの創業者やエンジニアは、依然として伝統的なモデルを沿用しています。一部は移行を検討し始めていますが、実際に一歩を踏み出す者は寥寥です。

記者の友人は、このテーマについて約 5 人にインタビューしたと教えてくれました。彼女は私たちに言いました。「あなたたちは誰よりも先に進んでいます。『あなたたちほど、ワークフロー全体を完全に再構築した人はいない』と感じます。」

どのチームでも、既存のツールを用いてこれを実現できます。私たちの技術スタック（Tech Stack）には、独占的な秘密は一つもありません。

真の競争優位性は、これらのツールを中心にすべてを再構築するという決意と、それに伴う莫大な代償を支払えるかどうかにかかっています。この代償は真に金銭的かつ痛烈なものです：従業員の混乱と不安、CTO が 1 日 18 時間働く苦難、シニアエンジニアの自己価値への疑念、そして旧システムが解体され新システムがまだ稼働していない、息を呑むような 2 週間の空白期間。

私たちはこれらの代償を支え抜きました。2 か月後、データがすべてを物語りました。

私たちはエージェントプラットフォームを構築しました。そしてこのプラットフォームは、エージェント自身によって構築されたものです。