『エンタープライズシステムへのAI駆動開発の適用』に向けた戦略における3つの重要論点

はじめに

AIネイティブ時代において、技術の進化速度は加速の一途をたどっています。LLMの性能は飛躍的に向上し、毎週のように新しいAI開発ツールが登場します。そのたびに「最適な開発プロセス」は再定義され続け、市場にはまだ確立されたデファクトスタンダードが存在しません。個人も組織も試行錯誤を繰り返しているのが現状です。

特にエンタープライズ企業にとって、この状況は深刻な課題です。スタートアップのように組織やプロセスを即座に刷新することは、多くのステークホルダーを持つ大企業には困難だからです。一度構築した組織体制や開発プロセスは一朝一夕には変えられません。しかし、最適解が常に変わり続ける現状では、計画の修正を延々と繰り返すことになり、現場は疲弊し、意思決定は遅延してしまいます。

このようなVUCAの時代において、ツールの変遷に左右されないための「揺るがない指針」が必要です。多くの組織は、目先のツールの機能比較に終始し、この本質的な軸を捉えきれていないように見えます。

エンタープライズ企業をはじめ多くの企業が求めているのは、個別のツールの導入マニュアルではなく、技術トレンドが変化しても揺るがない「普遍的な論点」を見極めることです。変わり続ける技術（Variable）と、変わらない開発の本質（Constant）を見極め、後者を強固な基盤として定義できれば、それはAI時代を勝ち抜くための強力な資産となります。

戦略の核となる3つの重要論点

図1: 戦略における3つの重要論点

ツールやモデル（How）は時代とともに変化します。しかし、システム開発において「どのような背景・制約のもとで（Context & Constraints）」「どのようなプロセスで（Excellent Workflows）」「誰がどのような責任を担うか（Responsible People）」という構造自体は不変です。この3点に投資することこそが、技術トレンドに左右されない開発体制を築く鍵となります。

以下では、まず「Context & Constraints」でAIに与えるべき情報基盤を解説し、次に「Excellent Workflows」でその情報基盤を活かす開発プロセスを示し、最後に「Responsible People」で各ロールがどのように変化すべきかを解説します。

1. Context & Constraints

図2: Context & Constraintsの定義

John Perkins氏は、あらゆるAIソリューションにおいて「コンテキスト・エンジニアリング」が極めて重要であると強調しています。プロジェクトのコンテキスト（Context）や制約（Constraints）を適切に与えることで、AIが生成するコードは「汎用的なコード」から「その企業の5〜10年目の熟練エンジニアが書いたような、組織の慣例やパターンを反映したコード」へと質が向上するからです。

これらは、初期のコンテキスト構築から始まり、プロトタイプ作成によるコンテキストの拡充、アーキテクチャ図による制約の明文化、そしてMCPを用いた動的な情報の取り込みに至るまで、段階的に「メモリバンク」を充実させていくプロセスです。

コンテキスト・ヒープ（Context Heap）の構築

プロジェクトの開始段階において、Solution Ownerが中心となり初期のコンテキストを構築します。具体的には、要件定義セッションの録画・記録から始め、プロジェクトチャーターをAIツールと対話しながらブラッシュアップし、ペルソナを作成するといった形で、反復的に「コンテキスト・ヒープ」へ蓄積していきます。

プロトタイピングによるコンテキストの拡充

続いてExperience ArchitectがGitHub Copilotを用いてSPA（シングルページアプリケーション）形式のプロトタイプを作成します。これは単なる試作ではなく、このプロトタイピングによってコンテキストと制約の拡充にも繋がります。

制約の明文化

コンテキストに加え、明確な「制約」を与えることも不可欠です。デザインシステム（フォント、カラー、コンポーネント群）を取り込み、Technical ArchitectがMermaidを活用してアーキテクチャ図を作成します。これにより、AIが生成するコードを特定のアーキテクチャやルールに準拠させることができます。Slalom社では、プロジェクトのライフサイクル全体を通じてC4レベルのアーキテクチャ図を維持し続けることをベストプラクティスとしています。

MCP（Model Context Protocol）による動的コンテキスト

静的なファイルだけでなく、MCPサーバーを経由して「動的コンテキスト」を取り込むことも重要です。例えば、データベースのスキーマ情報を動的に読み込んで正確なデータアクセスコードを生成したり、クラウド基盤のドキュメントを参照してInfrastructure as Codeの記述を検証したりすることが可能になります。

メモリバンク化

これら蓄積された「コンテキスト」と「制約」をすべてMarkdownで表現し、体系化して、GitHub Copilotが常に参照できる「メモリバンク」として構成します。LLMはテキスト理解に非常に優れているため、これらのドキュメント群がそのまま強力なガードレールとして機能します。

2. Excellent Workflows

コンテキストが整備されたとしても、開発者が非効率なプロセスに縛られていてはその効果を最大化できません。SDLC（ソフトウェア開発ライフサイクル）を変革するための鍵は、GitHub Copilotの「Agent Mode」と、IDEを中心としたワークフローの統合です。

Agent Mode

GitHub CopilotのAgent Modeにより、明確な目的（Objective）を設定し、コンテキストと制約、そしてMCPを活用してコードを書かせることが可能になります。また、開発プロセスの一部として存在する非同期のエージェントワークフローをMCPサーバーとして公開し、Copilotから呼び出せるようにすることで、開発者は待ち時間なく作業を進めることができます。

Single Pane of Glass

Single Pane of Glassとは、複数のシステムやツールを一つの画面から操作・確認できる状態を指します。目指すべき未来の開発像は、IDE（VS Code等）とGitHub Copilotがこの「Single Pane of Glass」となり、開発者がJira、データベース、ドキュメントなど様々なツールを行き来することなく、すべての作業がIDEの中で完結する世界です。 開発者はIDEから離れることなく、「JiraのストーリーXを実装して」と指示するだけでよいのです。CopilotはMCPを通じてJiraの要件を読み、メモリバンクの制約を参照し、必要なデータベース操作のコードを書き、完了すればJiraを更新します。ツール間のコンテキストスイッチを極限まで減らすワークフローこそが、生産性を向上させます。

3. Responsible People

ここでは各ロールの新しい役割を整理します。SDLCの変革に伴い、各ロールの役割は「コードを書くこと」から、「AIのためのコンテキストと制約を定義すること」へと進化します。組織のナレッジやベストプラクティスを抽出・蒸留し、AIが利用可能な形に落とし込むことが、開発に関わる各ロールの新たな責務となります。

Solution Owners / Business Systems Analysts

要件定義セッションをすべて記録し、追加のコンテキストを収集します。さらに、Few-shotプロンプティングを活用してプロジェクトディスカバリーの成果物を作成し、プロダクトコンテキストの基礎を築きます。

Experience Architects & Designers

プロジェクトコンテキストを活用し、デザインシステムを組み込みつつ、GitHub Copilotを用いてSPAのプロトタイプを作成します。このプロトタイピングを通じて、AIが参照するコンテキストと制約が拡充されていきます。

Technical Architects

Mermaidを用いてアーキテクチャ図を作成し、開発チームの認識を合わせると同時に、GitHub Copilotが生成するコードをそのアーキテクチャに沿ったものに制約します。製品のライフサイクル全体を通じて、C4レベルのアーキテクチャ図を維持し続けることが推奨されます。

Developers, Quality Engineers, and DevOps Engineers

コンテキストと制約に加え、MCPサーバー経由の「動的コンテキスト」を組み合わせて活用します。これにより、開発速度を飛躍的に向上させるだけでなく、正確性と一貫性も担保します。

おわりに

本稿で論じてきたように、AIネイティブ時代において真に重要なのは、最新のツールを追いかけることではなく、「どれだけ自社のコンテキスト（Context）と制約（Constraints）をAIに正しく伝えられるか」です。

「Context & Constraints」「Excellent Workflows」「Responsible People」の3つの論点を整備することは、単なる効率化ではありません。それは、組織の暗黙知を形式知化し、AIを用いて全開発者がその恩恵を受けられるようにする、まさに「組織独自の競争優位性」の構築プロセスです。大手エンタープライズ企業として、顧客のシステム開発に変革をもたらすために、まずは自社の開発プロセスにおいてこの「コンテキスト・エンジニアリング」を実践し、ナレッジを蓄積していくことを推奨します。