MetaのGenAIチーム（LLaMA）出身のCo-FounderであるPeter Pang（@intuitiveml）が率いるエージェントプラットフォーム企業CreaoAI（25名）が、「AIファースト」を本気で実践した結果、コードの99%をAIが書き、かつてのリリースサイクル6週間を1日に短縮した方法を解説している。

元記事タイトルは “Why Your ‘AI-First’ Strategy Is Probably Wrong”。@SuguruKun_ai がX（旧Twitter）のスレッドで日本語解説している。

AIを「導入した」会社と「前提に組み直した」会社の違い

多くの企業は既存のプロセスにAIを乗せています。エンジニアがCursorを開き、PMがChatGPTで仕様書を書く――ワークフローは変わらず、効率が10〜20%上がるだけです。

AIファーストとはまったく別物です。AIファーストとは、「AIがメインのビルダーである」という前提でプロセス・アーキテクチャ・組織を再設計することです。「どうすればAIがエンジニアの役に立てるか？」ではなく、「どう再構築すればAIがビルドし、エンジニアが方向と判断を提供できるか？」という問いです。

ハーネスエンジニアリングとは何か

OpenAIが2026年2月に発表した概念で、CreaoAIが実践の中で独自に到達していたアプローチと一致しました。

エンジニアリングチームの主な仕事はもはやコードを書くことではなく、エージェントが有用な作業を行える「環境（ハーネス）」を整えることである。

失敗が起きたとき、解決策は「もっと頑張れ」ではなく「どのケイパビリティが欠けているか、エージェントにとって読み解けるようにするにはどうすればよいか」を問うことです。

3つのボトルネックを解消した

CreaoAIはAI移行前に3つの深刻な問題を抱えていました。

① プロダクトマネジメントのボトルネック

エージェントは2時間でフィーチャーを実装できます。数週間の計画サイクルがボトルネックになります。仕様書レビューではなく、プロトタイプ→リリース→テスト→反復のループで動く必要があります。

② QAのボトルネック

ビルド時間2時間・テスト時間3日では話になりません。AIが書いたコードをAIが構築したテストプラットフォームで検証し、バリデーションを実装と同速度で動かします。

③ ヘッドカウントのボトルネック

競合は100倍の人員。CreaoAIは25名。採用では追いつけないため、設計で追いつく必要がありました。

アーキテクチャ統合：モノレポへ移行した理由

複数リポジトリにまたがる変更はAIエージェントにとって「不透明」でした。AIは全体像を把握できず、クロスサービスの影響を推論できません。

モノレポへ統合した一番の理由：AIがすべてを見られるようにするため。

ハーネスエンジニアリングの原則では「エージェントが検査・検証・変更できる形にコードを引き込むほどレバレッジが増す」とされる。1週間かけて新設計を策定し、さらに1週間でエージェントを使ってコードベース全体をリアーキテクチャした。

技術スタック詳細

インフラ：AWS

自動スケーリングのコンテナサービスとサーキットブレーカーロールバックで運用。デプロイ後にメトリクスが劣化すると自動でリバートします。CloudWatchを中枢神経系として使い、25以上のアラームとカスタムメトリクスで全サービスから構造化ログを収集します。

CI/CD：GitHub Actions（6フェーズ）

1

Verify CI → Build/Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release

CIゲートは型チェック・リント・ユニットテスト・統合テスト・Dockerビルド・Playwright E2Eテスト・環境パリティチェックをすべて必須で実施。手動オーバーライドは存在しない。パイプラインが決定論的であるため、エージェントが結果を予測して障害を推論できる。

AIコードレビュー：Claude Opus 4.6

PRのたびに3つのClaudeレビューパスを並列実行します。

  1. コード品質 — ロジックエラー、パフォーマンス問題、保守性
  2. セキュリティ — 脆弱性スキャン、認証境界チェック、インジェクションリスク
  3. 依存関係スキャン — サプライチェーンリスク、バージョン競合、ライセンス問題

1日8回デプロイする状況で人間レビュアーがすべてのPRに集中し続けることは不可能だ。これはサジェスチョンではなくレビューゲートである。

自己修復フィードバックループ

毎朝9:00 UTC、自動ヘルスワークフローが起動します。

  1. Claude Sonnet 4.6がCloudWatchを照会してエラーパターンを分析
  2. 全サービスのエグゼクティブヘルスサマリーをMicrosoft Teams経由で配信
  3. 1時間後、トリアージエンジンが起動
  4. CloudWatchとSentryの本番エラーをクラスタリングし、9つの深刻度次元でスコアリング
  5. Linearにサンプルログ・影響ユーザー・影響エンドポイント・調査パス付きのチケットを自動生成
  6. エンジニアが修正をプッシュすると同じパイプラインで処理→CloudWatchを再確認→解決済みならチケット自動クローズ

フィーチャーフラグ：Statsig

フィーチャーはすべてゲート付きでリリース。チーム有効化 → 段階的パーセンテージロールアウト → 本リリースまたはキル。デプロイ不要でキルスイッチが即時有効になります。

PR管理：Graphite

Graphite は GitHub の PR ワークフローを拡張する開発者ツールで、CreaoAI では主に マージキュー と スタックドPR の2機能を活用している。1日8回デプロイ・AIが大量にPRを生成する環境では、素の GitHub PR フローは簡単に破綻するため、この2つがスループットの鍵になる。

マージキュー（Merge Queue）

複数の PR が同時にマージ待ちになったとき、Graphite が順番にキューイングして以下を自動実行する。

  1. 対象 PR を最新の main にリベース
  2. リベース後のコードで CI を再実行
  3. すべてグリーンなら自動マージ、赤ければキューから除外して通知

「レビュー時は緑だったのに、他の PR とマージ順が前後したせいで main が壊れる」という事故を構造的に防げる。AI が並列に PR を量産する運用ではこのガードが必須になる。

スタックドPR（Stacked PRs）

1 つの大きな変更を、依存関係のある 小さな PR の連鎖 に分割してレビューする手法。

1
2
3

PR #1: DBスキーマ追加  ← main
  └ PR #2: APIエンドポイント追加  ← PR #1 に依存
      └ PR #3: フロント実装          ← PR #2 に依存

従来の GitHub では「親 PR がマージされるまで子 PR が作れない」ため開発が直列化するが、Graphite は依存関係を保ったまま各 PR を独立にレビュー・マージ可能にする。結果として、

  • レビュアーは 100〜200 行単位の小さな差分だけを見ればよい（AI レビューも人間レビューも精度が上がる）
  • エージェントは次の PR を「待ち」なしで積み上げられる
  • 親 PR が修正されれば子 PR の差分も自動で追従する

なぜハーネスに効くのか

AI がコードを書く速度に対して、レビューとマージが詰まるとハーネス全体の律速になる。Graphite は「レビュー粒度を細かくしてスループットを上げる（スタックドPR）」と「main を壊さずに並列マージを捌く（マージキュー）」を同時に解決するため、AIファースト運用と相性が良い。

新しいエンジニアリング組織：2タイプへの再定義

Architect（1〜2名）

AIの仕組みを設計する人。テストインフラ・統合システム・トリアージシステムを構築し、アーキテクチャとシステム境界を決定する。AIを批判する役割であり、AIに従わない役割だ。

私は物理学のPhDを持っています。PhDで最も役立ったのは、仮定に疑問を投げかけ、議論をストレステストし、欠落しているものを探す方法を学んだことです。AIを批判できる能力は、コードを生産できる能力よりも価値が高くなるでしょう。

Operator（全員）

AIの成果を検証・判断する人。AIがタスクを割り当て、エンジニアが調査・検証・承認します。バグ調査、UIの改善、CSSの修正、PRレビュー、検証が主な業務です。

実績

14日間で平均3〜8回/日の本番デプロイを達成。以前のモデルでは同じ2週間で本番リリースは1回もなかったはずです。

  • 問題のあったフィーチャーは出荷当日にキルスイッチで無効化
  • 新フィーチャーは着想当日に本番稼働
  • A/Bテストをリアルタイムで検証

「スピードのために品質を犠牲にしているのでは」という先入観に反して、ユーザーエンゲージメントと決済コンバージョンが向上しました。フィードバックループが緊密になるほど、学習が増えるためです。

適応が速いのはジュニアエンジニア

予想外のパターンがありました。ジュニアエンジニアの方がシニアよりも速く適応しました。従来の習慣を持たないジュニアは、AIを活用して影響力を増幅させることに抵抗がありません。一方、熟練したシニアエンジニアにとって、2ヶ月分の仕事がAIに1時間でできることを受け入れるのは困難です。

組織全体への展開

エンジニアリングだけAIファーストにして他を手動のままにすると、今度は他がボトルネックになります。CreaoAIではすべての機能にAIを展開しました。

  • プロダクトリリースノート：変更ログと説明からAI生成
  • フィーチャー紹介動画：AIモーショングラフィクス
  • SNS投稿：AIオーケストレーションで自動公開
  • ヘルスレポートと分析サマリー：CloudWatchとDBからAI生成

まとめ：CTOやFounderへの示唆

  1. PMのプロセスがビルド時間より長ければ、そこから着手する
  2. エージェントをスケールする前にテストハーネスを構築する（速いAIと速いバリデーションなしは、速く動く技術的負債）
  3. まずArchitectを1名用意し、システムを構築して検証してからOperatorをオンボードする
  4. すべての機能にAIネイティブを押し込む
  5. 抵抗を覚悟する

今後、1人+エージェントで100人分の仕事ができるなら、1人企業が当たり前になるでしょう。ツールはすでに存在します。あとはすべてを再設計する意思決定だけです。