ソフトウェアファクトリーとは？意味・AIエージェント時代の開発体制・導入の進め方

AIコーディングエージェントが、課題の読解、コード変更、テスト実行、プルリクエスト（PR）作成までを支援するようになり、「ソフトウェアファクトリー」という言葉を見聞きする機会が増えています。

ただし、この言葉は文脈によって指すものが異なります。歴史的には、大規模ソフトウェア開発を専門組織と標準工程で扱う考え方を指す例があります。米国防総省（DoD）のDevSecOps文脈では、人・ツール・プロセスの集合として、継続的にソフトウェアを提供するための仕組みを指します。

AIエージェント時代の開発体制を説明する際にも便利な言葉ですが、AIエージェントを含む体制について、広く固定された業界標準の定義があるわけではありません。そこで本記事では、AIエージェントを含む開発工程を、共通の入力、実行環境、品質ゲート、権限、観測で運用する体制を、本記事での実務上の整理として「AIエージェント時代のソフトウェアファクトリー」と呼びます。

本記事は2026年9月24日に確認した公開情報を基に編集しています。導入手順、判定表、テンプレートはMojiによる実務上の提案です。業務の重要度、リポジトリの状態、利用モデル、入力仕様の品質、許容できない失敗に応じて調整してください。

結論：AI時代のソフトウェアファクトリーは「自動化の量」ではなく「再現可能な開発・統制の仕組み」

AIエージェント時代にソフトウェアファクトリーを検討する目的は、コード生成を速くすることだけではありません。チームや案件が変わっても、変更を安全に作成、検証、承認、リリースできる状態を再現しやすくすることです。

• 要件と受入条件を、実装・テストへ渡せる粒度で残す
• 開発者とエージェントが使う環境、依存関係、秘密情報の扱いを定める
• 変更ごとに、テストや静的解析などの検査を実行できるようにする
• PRレビュー、承認、リリース権限、ロールバックの責任分界を明確にする
• 品質、セキュリティ、コスト、リードタイムを記録し、工程を見直せるようにする

したがって、初期に目指す対象は「最も自律的なエージェント」ではなく、失敗時に止められ、結果を比較できる1本の変更ラインです。

AIエージェントそのものの定義、生成AI・チャットボット・RPAとの使い分けは、AIエージェントとは？生成AI・チャットボット・RPAとの違いと導入判断・実践手順で解説しています。

ソフトウェアファクトリーには3つの用法がある

検索や社内議論での混同を避けるため、少なくとも次の3つを分けて扱います。

1. 日立の「ソフトウェア工場」の例：専門組織としての開発

日立の沿革では、1969年に、ソフトウェア開発を本格的に一貫して行うソフトウェア専門事業所として、ソフトウェア工場が神奈川工場から独立したと説明されています。この事例で中心となるのはAI活用ではなく、ソフトウェア開発を専門組織として担うための組織設計です。日立：ソフトウェア事業部のご紹介／事業のあゆみ

2. DevSecOps基盤としての用法：人・ツール・プロセスを含む構成

DoDの「Enterprise DevSecOps Fundamentals」は、ソフトウェアファクトリーを、特定のエンドユーザーコミュニティのニーズに応えるためにソフトウェアをデプロイし、継続的に価値を提供できるようにする、人・ツール・プロセスの集合として説明しています。同資料の能力図には、開発・テスト・統合の環境、CI/CDパイプライン、ログ集約・保管と分析・表示、継続的モニタリングが含まれます。DoD Enterprise DevSecOps Fundamentals v2.5

この用法で重要なのは、ファクトリーを単一のCI/CDツールや単一アプリと同一視しないことです。人、開発環境、パイプライン、検証・昇格のゲート、ログ・監視などを、継続的な開発と提供の仕組みとして扱います。

3. AIエージェント時代の用法：AIを「工程に組み込む」ための実務上の整理

本記事では、AIエージェントが課題や仕様を読み、リポジトリ内で変更を作成し、テストを実行してPRを作るような工程を、共通のルールと統制の下で運用する体制を指します。これは特定の製品や組織が定めた唯一の定義ではなく、前述した日立の事例とDoDのDevSecOps上の用法と区別するための編集上の整理です。

GitHubは、Copilot cloud agentについて、課題を割り当てると作業を開始してPRを作成する流れを案内しています。完了後は、通常のPRと同様に人が変更をレビューし、必要に応じて修正依頼、承認、マージを行う手順です。GitHub Docs：Get started with Copilot agents on GitHub

AIエージェント時代の構成：エージェントを中心に置かない

ツール導入だけで終わらせないために、Mojiでは次の6層で整理することを提案します。

1. 仕事の入口：課題、背景、変更範囲、受入条件、禁止事項をチケットや仕様として残す。
2. 実行環境：リポジトリ、依存関係、テストデータ、ネットワーク、シークレットへのアクセス範囲を定める。
3. 作業者：開発者、AIコーディングエージェント、レビュー支援ツールが役割ごとに作業する。
4. 品質ゲート：ビルド、テスト、静的解析、依存関係・秘密情報の検査などを実行する。
5. 意思決定ゲート：設計判断、PR承認、デプロイ承認、例外承認を誰が担うかを残す。
6. 観測と改善：成功・失敗、差し戻し理由、障害、実行時間、費用を記録して見直す。

この整理では、AIエージェントは3層目の「作業者」です。品質検査や意思決定までを無条件に委ねるのではなく、各工程で検出・停止・承認できる構成を設計します。NISTのSSDFは、安全なソフトウェア開発の実践を、組織準備、ソフトウェア保護、安全なソフトウェアの生産、脆弱性対応の4グループに整理しています。NIST SP 800-218：Secure Software Development Framework

導入前の判断：本当にソフトウェアファクトリーが必要か

すべてのチームが、最初から大きな共通プラットフォームを構築する必要はありません。以下はMojiによる判断の目安です。

特に、仕様と受入条件がないままエージェントへ実装を依頼すると、出力の適否を同じ基準で比較できません。生成AI導入の対象業務を棚卸しし、対象工程、責任者、評価方法を決める手順は、生成AI導入前の業務棚卸しと現場定着の進め方も参考にしてください。

導入の進め方：1本の「安全な変更ライン」から始める

ステップ1：対象を「小さく、戻せる変更」に限定する

初期の対象は、影響範囲を限定しやすく、ロールバックでき、テストで確認しやすい作業が候補です。たとえば、既存APIへの項目追加、テスト不足箇所へのテスト追加、内部管理画面の表示修正、ドキュメントと実装の不整合検出などです。

一方、認可設計の全面変更、本番データ移行、決済確定、顧客への自動送信、インフラ削除のような変更は、初期の自律実行対象から外す判断が考えられます。委任範囲、人の承認、停止条件の考え方は、AIエージェントはどこまで任せるべきか｜委任範囲・人の承認・停止条件を設計する実務ガイドで詳しく整理しています。

ステップ2：入力仕様を「作業指示」ではなく「検証可能な契約」にする

AIエージェントに渡すチケットには、少なくとも目的、変更してよい範囲、変更してはいけない範囲、受入条件、テスト方法、データ・権限上の制約を含めます。

チケットテンプレート（Mojiによる提案）

目的：何を利用者・運用者に提供するか
変更範囲：対象リポジトリ、対象モジュール、対象画面
変更禁止：認証方式、課金ロジック、公開APIの破壊的変更など
受入条件：期待する振る舞いを「条件→結果」で列挙
確認方法：実行すべきテスト、手動確認、スクリーンショット要否
制約：利用可能な依存関係、データ分類、ネットワーク・権限
完了条件：PR、テスト結果、変更概要、既知の未解決事項

このテンプレートは架空の例です。アーキテクチャ、変更管理、監査上の要件に合わせて項目を増減してください。

ステップ3：権限を「読む・提案する・変更する・公開する」に分ける

エージェントの権限は、利便性だけでなく、誤操作時の影響と復旧可能性を基準に決めます。Mojiでは、次の4段階を分けて検討することを提案します。

1. 閲覧：コード、仕様、ログを読む。
2. 提案：設計案、差分案、テスト案を出すが、書き込まない。
3. 変更：隔離ブランチや一時環境でコード・設定を変更する。
4. 外部影響のある実行：マージ、デプロイ、送信、削除、課金などを行う。

初期段階では「閲覧＋提案」または「隔離環境での変更」までに範囲を留め、PR承認、本番デプロイ、外部送信は人または既存の承認ワークフローに残す方法があります。OWASPは、下流システムで利用者ごとの認可文脈と必要最小限の権限を用いること、高影響な操作の前に人の承認を求めることを対策として挙げています。OWASP：LLM06:2025 Excessive Agency

ステップ4：エージェントの実行環境を開発者環境から分離する

エージェントが実行するコマンド、参照できるディレクトリ、ネットワーク接続先、利用できるトークンを限定します。開発者個人の端末にある認証情報や、本番相当の資格情報をそのまま利用させない設計を検討してください。

たとえばClaude CodeのCLIには、権限プロンプトを省略する--dangerously-skip-permissionsオプションがあります。公式CLIリファレンスでは、このオプションは--permission-mode bypassPermissionsと同等であると説明されています。組織標準に採用する場合は、用途、実行環境、代替となる権限制御、監査方法を個別に確認します。Anthropic：Claude Code CLI reference

ステップ5：品質ゲートをPRより前と後に置く

PRが作られたこと自体を完了条件にはしません。Mojiでは、ビルド、テスト、静的解析、秘密情報検出、依存関係確認を実行し、PRへ変更意図、テスト結果、未解決事項を残す構成を提案します。

GitHubは、第三者コーディングエージェントがコードを作成・変更した際、CodeQLによるコードスキャン、シークレットスキャン、新規依存関係に対するGitHub Advisory Databaseでの確認を行う仕組みを案内しています。ただし、これはGitHub上の当該機能に関する説明であり、他の開発環境やエージェントで同等の検査が行われることを意味しません。GitHub Docs：About third-party coding agents

ステップ6：評価を「最終回答」ではなく工程別に行う

AIエージェントの評価では、コードが動いたかだけでなく、仕様理解、変更範囲の遵守、テストの妥当性、セキュリティ、レビュー負荷、実行時間、費用を分けて記録します。

NIST AI RMF Coreは、AIリスク管理をGovern、Map、Measure、Manageの4機能で整理しています。Governは他の機能を横断し、Mapでは利用文脈や人の監督を扱い、Measureでは導入前・運用中の評価と文書化、Manageでは優先度付けと対応を扱います。NIST：AI RMF Core

評価設計の基本は、AIの評価とは？評価指標や評価方法、その費用についても参照してください。

PoCで比較する評価表

以下はMojiによる評価表です。モデルやエージェント製品を順位付けする表ではありません。同一のリポジトリ、同一の課題群、同一の権限、同一のテスト環境で比較してください。結論は、入力仕様の品質、変更の難易度、評価指標、許容誤差で変わります。

評価課題には、成功例だけでなく、曖昧な仕様、変更禁止領域への誘導、テストが失敗する変更、権限外の要求も含めます。これにより、実運用で起き得る失敗を、導入前に確認しやすくなります。評価データの設計と更新の考え方は、RAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説も参考になります。

よくある失敗と修正方法

失敗1：AI導入を先に決め、工程のボトルネックを見ていない

レビュー待ち、テストデータ不足、環境差分、承認待ちが主な遅延要因なら、コード生成を増やしても全体のリードタイムが改善しない場合があります。作業開始から本番反映までの待ち時間を分けて記録し、繰り返し起きる待ちに対して共通化・自動化を検討します。

失敗2：エージェントに広い権限を渡してから、ルールを考える

本番環境や顧客データへのアクセス、マージ、デプロイ、送信の権限を初期から広く渡すのではなく、最小権限、実行環境の分離、明示的な承認、監査記録、停止手順を先に設計します。NIST AI RMFでは、人とAIの役割・監督を定義し、リスクの測定と対応を継続する考え方が示されています。NIST：AI RMF Core

失敗3：CIの成功を品質保証と誤認する

CIが成功しても、要件解釈、境界条件、UX、データ移行、運用手順まで正しいとは限りません。自動テストで判定できる条件と、ドメイン担当者やレビューアが確認する条件を分けて管理します。

失敗4：各チームが独自のプロンプト・権限・ログ形式で運用する

個別最適のまま横展開すると、監査、障害対応、モデル変更、費用管理を横断して比較しにくくなります。すべてを中央集権化する必要はありませんが、「利用可能なデータ区分」「権限階層」「必須ログ」「品質ゲート」「例外申請」は共通化の候補です。

導入チェックリスト

対象業務

• 対象の変更は、初期段階ではロールバック可能か
• 受入条件と変更禁止領域が文書化されているか
• 人がレビューできる単位に変更を分割できるか

権限・セキュリティ

• エージェントのID、利用可能なツール、データ範囲を把握できるか
• 本番への書き込み、公開、送信、削除には別の承認を要求しているか
• シークレットをプロンプト、ログ、成果物に残さない仕組みがあるか
• 異常時にトークン無効化、実行停止、ロールバックを行えるか

品質・運用

• ビルド、テスト、静的解析、依存関係・秘密情報確認を品質ゲートに置いているか
• 実行した指示、利用モデル、ツール呼び出し、生成差分、テスト結果を追跡できるか
• 失敗例を含む評価課題を用意し、導入前後を同条件で比較できるか
• モデル、ツール、ルールを変更した際に再評価する手順があるか

まとめ

ソフトウェアファクトリーは、日立の事例ではソフトウェア開発を専門組織として一貫して行う体制を指します。DoDのDevSecOps文脈では、人・ツール・プロセスの集合として、継続的にソフトウェアを提供するための仕組みとして説明されています。

AIエージェント時代については、本記事では、AIを含む開発工程を統制・評価する体制として実務上整理しました。重要なのは、AIに仕事を多く任せることではなく、仕様、権限、実行環境、品質ゲート、人の承認、観測を一続きに設計することです。

まずは小さく戻せる変更を対象に、隔離環境でエージェントがPRを作成し、人がレビューし、評価結果を次の標準化へ戻す変更ラインを作ります。その結果を基に、委任範囲と共通基盤を段階的に広げてください。