AIソフトウェアファクトリとは何か？3つのクライアント導入事例からの教訓

ダークファクトリベンダーに騙されないでください — ライブセッション、9月29日。席を確保する × お問い合わせ AIソフトウェアファクトリとは？3つのクライアント導入事例からの教訓 2026年9月23日 AI, ソフトウェアファクトリ Vitaly Filipov デジタルトランスフォーメーション＆リーダーシップ 目次 長い一日を終え、ベッドでこれを書いています。明白に見えることを説明しようとしていますが、articulateするたびに曖昧に感じます。現在のブログ記事が、ソフトウェアファクトリとは何かを説明する上で最良のものだと思います！しかし、それはあなた次第です… AIソフトウェアファクトリとは、AIエージェント、連携ツール、自動チェック、人間の監視を使用して、定義された要件を検証済みのソフトウェア変更に変換するための管理システム（管理されたハードウェアとしてのクラウドサーバーのようなもの）です。最高のAIソフトウェアファクトリプラットフォームを比較する際は、エージェントの数やインターフェースから始めないでください。システムが意図、コンテキスト、実行、検証、承認、リリース、フィードバックを接続できるかどうかから始めてください。まったく、たくさんありましたね…もう少し息を止めましょう。エージェントのワークフローが含まれます。作業がどのように開始され、どのようなコンテキストが利用可能で、どのようなアクションが許可され、結果がどのように受け入れられるかです。Camplightでは、過去9ヶ月間ソフトウェアファクトリを構築しており、3つのクライアント向けに導入しました。これらの実装はNDAで保護されています。クライアントシステムをまだ公開できません。代わりに、実装経験を一般化してNestを構築しました。これは、機密性の高いデプロイメントを明らかにすることなく、運用上の質問と構築ブロックを可視化する公開モデルです。これはオープンソースのOrgOpsインフラに基づいています。Nestは、3つのクライアントデプロイメントからのパターンに基づいた、主要な人間主導のAIソフトウェアファクトリのCamplightモデルを可視化します。これは、最終的に構築するかもしれないものの予測ではありません。すでに実施している作業を説明する方法です。以下のスクリーンショットは、3つの機密クライアント環境のいずれかではなく、統一された一般化されたモデルを示しています。これらは、すべてのデプロイメントに表示されているすべてのインターフェースが含まれていることを意味するものではありません。名前、予算、タイミング、パフォーマンスの数値は例示であり、公開されたクライアントの結果ではないことを disclaimerとして追加したいと思います。主要なAIソフトウェアファクトリプラットフォームを比較する際には、これらの画面を普遍的な製品チェックリストではなく、評価フレームワークとして扱ってください。数ヶ月後には別のブログ記事を書く必要があるでしょう。この分野は非常に速く動いているからです…有用な質問は、あなたの会社がNestと全く同じインターフェースを必要とするかどうかではありません。それは、その背後にある運用上の質問に答えられるかどうかです。この実践的なガイドは、UberのAIソフトウェアファクトリの分析と、ダークファクトリの準備状況の調査に基づいています。ここでは、システムに何が含まれているか、作業がどのように進むか、そしてリーダーがどのように管理する必要があるかに焦点を当てます。AIソフトウェアファクトリはコーディングエージェントとどう違うのか？コーディングエージェントは substantialな開発作業を実行できます。例えば、GitHubのCopilotクラウドエージェントは、リポジトリを調査し、変更を計画し、コードを修正し、開発環境でテストを実行できます。したがって、ソフトウェアファクトリは、「当社のAIはオートコンプリート以上のことをする」と言うだけで区別することはできません。区別は、実行を取り巻くシステムです。私たちが使用するモデルでは、ソフトウェアファクトリはビジネスリクエストを、それを実現するために必要なコンテキスト、ツール、人々、検証、およびリリースプロセスに接続します。定義された意図 -> 関連コンテキスト -> 実行 -> 検証 -> 必要な承認 -> リリース -> フィードバック そのフローの異なる部分は、異なるメカニズムを使用できます。一部はエージェントを必要とします。他のものは、通常のコード、既存のパイプライン、または人間によってより良く処理されます。（ヒント：evalsとガードレールは常に変化するターゲットであるため、通常、ボトルネックは検証の周りです）AIソフトウェアファクトリは、継続的インテグレーションとデリバリー（CI/CD）を置き換えるものでもありません。CI/CDはすでに変更のビルド、テスト、デプロイのメカニズムを提供しています。ファクトリは、エージェントによって生成された作業をこれらのメカニズムに接続する必要があります。コーディングエージェントは作業を実行します。ソフトウェアファクトリは、その作業が誰でもトリガーできる、受け入れられ、説明責任のあるソフトウェア変更にどのように変わるかを定義します。重要なのは「誰でも」ですが、後でまた触れます。この用語自体はさまざまな方法で使用されています。Cortexは組織的なソフトウェア配信システムを説明し、StrongDMは人間のコードレビューなしの意図的に非対話的なアプローチを説明しています。私たちのスコープは、自律性、検証、介入に関する明示的な決定を伴う、人間主導のAIソフトウェアファクトリです。なぜなら、誰も完全なダークステートに到達していないからです。最高のAIソフトウェアファクトリに共通すること：7つの構築ブロックNestは、リーダーがAIソフトウェアファクトリプラットフォームを比較するために使用できる7つの領域を中心に構成しました。運用可視性、エージェント管理、構成、プロジェクト、チームアセンブリ、再利用可能な機能、および人間とのコラボレーションです。これらは、主要なAIソフトウェアファクトリの評価基準であり、7つの新しいアプリケーションを構築する必要があるわけではありません。1. 運用ダッシュボード：何が起こっていて、何に注意が必要ですか？最高のAIソフトウェアファクトリプラットフォームは、支出、タスク、問題、プロジェクト、注意点を1つの運用ビューに変換します。ダッシュボードは、会話から再構築することなく、人がファクトリの状態を理解できる場所であるべきです。mIRCとのミレニアル世代の時代は大好きでしたが、チャットは非常に疲れます。何が実行されていますか？何が完了しましたか？何がレビュー待ちですか？どの問題が介入を必要としていますか？実行コストはいくらですか？asl pls？Nestは、支出、タスク、問題、アクティブプロジェクト、コミュニティを通じてこれらの質問を統合します。重要な設計上の選択は、可視性をアクションに接続することです！ブロックされたタスクは、そのコンテキストにつながるべきです。支出の異常は、関連するワークフローにつながるべきです。レビューリクエストは、成果物とそれを承認するための基準につながるべきです。エグゼクティブにとって、アクティビティメトリクスとデリバリーメトリクスを区別することも重要です。「エージェントが100のタスクを完了しました」はアクティビティを説明します。それは、会社が100の有用な成果を受け取ったことを確立しません。私の好みの評価は、受け入れられた変更、経過したデリバリー時間、レビュー労力、手戻り、および実行コストを組み合わせたものです。比較可能な作業の場合、有用な測定値は次のとおりです。受け入れられた変更あたりのコスト = 定義された作業バッチの総実行およびレビューコスト / そのバッチで受け入れられた変更その計算には、成功した最終実行だけでなく、失敗した試行と再試行も含まれるべきです。ダッシュボードには、コミュニティからの小さな祝賀会や共有された作業も含まれています。それは意図的です。この環境が、単に増え続ける機械アクティビティのキューだけでなく、人々が協力して達成していることを示すことを望んでいます。管理上の質問：人は、今どこに最も注意を払うべきかを見ることができますか？2. エージェント管理：作業を中心に機能を整理する主要なAIソフトウェアファクトリは、各エージェントの役割、アクティビティ、パフォーマンス、およびステータスを可視化します。エージェントディレクトリは、名前とアバターをリストする以上のことをすべきです。それは、責任を理解できるようにすべきです。各エージェントは何をしますか？どこで動作しますか？誰がその構成を所有していますか？アクティブですか、一時停止中ですか、それともヘルプを待っていますか？ここで、水平エージェントと垂直エージェントの質問が役立ちます。水平機能は、再利用可能なリサーチワークフローなど、複数のチームをサポートする可能性があります。ドメイン固有の機能は、1つの製品、リポジトリ、またはビジネスプロセス内で動作する可能性があります。これらは設計上の選択であり、競合する宗教ではありません。共有機能は、重複作業を削減できます。1つのドメインに近い機能は、より明確なコンテキストとタイトな境界を持つことができます。正しい選択は、作業と組織に依存します。Team Topologiesは、チームの境界、共有プラットフォーム、およびインタラクションモードを考えるための有用な参照を提供します。それらのアイデアをエージェントに適用することは、アーキテクチャのアナロジーであり、人間のチームタイプがAIロールに直接マッピングされるという主張ではありません。会社の組織図をエージェントのコレクションとして再作成することから始めるべきではありません。