1127｜AIに社内システムの設計を任せたら、14分で立派なものができた
ある会社が、社員向けにAIを導入することになった。
社員は100名程度。そのうち20名が、まずAIを使い始める。ただし、文章を作ったり、調べ物をしたりするだけではない。
社内にある業務システムとも連携させたい。
例えば営業担当者がAIに、「今月の案件の進捗をまとめて」と質問すると、AIが営業管理システムから情報を取得し、進捗状況を整理して回答する。
人事担当者なら、「今月入社した社員の手続き状況を確認して」と尋ねるかもしれない。
もちろん、営業担当者が人事情報を自由に見られては困る。
AIが便利になる一方で、社内の情報をどこまで扱わせるのかという問題も生まれる。では、このような仕組みを構築するには、何が必要なのだろう。
今回はこの架空の会社を題材にAIとシステム構成を考えてみることにした。
AIと社内システムをつなぐ
まず、必要なのはAIと社内システムを接続する仕組みだ。
社員がAIに質問すると、その内容に応じて社内の業務システムから
情報を取得する。
大まかには、次のような構成になる。
社員のPC → AIサービス → 接続用サーバー → 社内業務システム
社員は普段利用しているAIの画面から質問する。
AIは必要に応じて接続用サーバーを経由し、社内システムの機能を呼び出す。
社内システムから返された情報をもとに、AIが回答を生成する。
ここで利用できる技術の一つに、MCP（Model Context Protocol）という仕組みがある。
MCPは、AIと外部のツールやデータを接続するための共通的な仕組みだ。MCPを使う場合、接続用サーバーの中でAIとの接続を担当する仕組みの一つとして「MCPサーバー」を利用できる。認証・認可や業務システムとのやり取りは、別の仕組みが担当する場合もある。
例えば、営業管理システムに案件情報を取得するAPI（システム同士がデータをやり取りするための窓口）があるなら、そのAPIをAIから利用できるツールとして公開することが考えられる。
社員が「今月の案件を確認して」と質問すると、AIが適切なツールを選び、必要な情報を取得する。
これなら、社員が毎回業務システムを開いて情報を集める手間を減らせるかもしれない。
ただし、ここで一つ問題がある。
そもそも、その会社ではMCPが必要なのだろうか。
MCPは便利だが、必須とは限らない
例えば、社員がAIを使って文章を作成したり、一般的な技術情報を調べたりするだけなら、社内システムとの接続は必要ない。
社内文書を検索したいだけなら、既存の文書検索機能やAIサービスが提供する連携機能で十分な場合もある。
特定の業務システムを操作したい場合には、APIやMCPを利用する意味が出てくる。
つまり、MCPが必要かどうかは、AIを使って何を実現したいのかによって
変わる。
ところが、最初から「MCPを利用した構成を作ってください」とAIに
依頼すれば、当然ながらMCPを使った構成案が出てくる。
技術的に成立する構成は作れる。しかし、それはMCPを採用する必要性が
検証されたことを意味しない。
この違いは、意外に大きい。
社内の情報を、誰が見てもよいわけではない
次に考えなければならないのは、認証と認可だ。
認証とは、利用者が誰なのかを確認すること。
認可とは、その利用者が何をしてよいのかを判断することだ。
例えば、営業担当者が営業管理システムにアクセスする場合、自分の
担当案件だけを見られる仕組みになっているかもしれない。
人事情報なら、閲覧できる社員がさらに限定されているだろう。
AIを経由したからといって、これらの制限がなくなってよいわけではない。
ここで考えられるのは、AIを利用している社員の権限を、
接続先の業務システムでも適切に確認する構成だ。
AIが案件情報を取得しようとした場合、接続用サーバーはその社員が
利用できる範囲の情報だけを返す。
これなら、AIが社内情報を取得する場合でも既存の権限管理を維持できる。
ここで注意したいのは、接続用サーバーが一つの共通アカウント（サービスアカウント）で業務システムにアクセスする場合だ。
共通アカウントを使うこと自体が問題なのではない。問題になるのは、
社員ごとの権限確認を省いてしまうことだ。
接続用サーバーの側で、質問した社員がその情報を見てよいのかを確認していれば、共通アカウントでも権限の範囲は守れる。しかし、その確認がなければ、誰がAIに質問しても同じ範囲の情報を取得できてしまい、営業担当者が人事情報を見られる状態にもなりかねない。
ただし、実際にどう実装するかは、業務システム側の認証・認可方式にも左右される。
ここでも、設計の前に確認すべきことがある。
その会社には、すでに共通の認証基盤（複数のシステムへのログインをまとめて管理する仕組み）があるのか。
業務システムごとに権限管理が分かれているのか。
社員ごとの権限をAPI経由で確認できるのか。
これらが分からなければ、認証・認可の仕組みを具体的に決めることはできない。
情報漏洩を防ぐ仕組みは、どこに置くのか
AIを社内システムと連携させるなら、情報漏洩も考える必要がある。
例えば、社員がAIに顧客情報を含む文章を入力する。
あるいは、AIが業務システムから取得した情報を、外部のAIサービスへ送信する。
どちらも情報が外部へ渡る可能性のある経路だ。
そこで、DLP（Data Loss Prevention）と呼ばれる情報漏洩対策を検討する。
DLPは、機密情報などの不適切な送信を検知したり、制御したりするための仕組みだ。
ただし、DLPを一か所に置けば、すべて解決するわけではない。
社員がAIの画面へ直接入力する情報と、社内システムからAIへ返す情報では、通過する経路が異なる。
そのため、端末側の制御と接続用サーバー側の制御を分けて考える必要がある。
さらに、情報を送信する前に防ぐ仕組みと、送信後に記録を確認する監査の仕組みも別物だ。
では、どこまで制御すればよいのだろう。
顧客名はすべて禁止するのか
契約金額はどうか
社員の氏名はどうか
社外秘の技術資料はどうか
ここは技術だけでは決まらない。
会社がどの情報を守る必要があり、どのような利用を許可するのかという
ルールが必要になる。
社内サーバーは、どの程度必要なのか
次に、社内側のサーバー構成を考える。今回は、既存の仮想化基盤を利用することにした。
仮想化基盤とは一台または複数の物理サーバー上で、複数の仮想マシンを
動かす仕組みだ。
例えば、AIとの接続を担当するサーバーと、業務システムへのアクセスを制御するサーバーを分けて配置する。
障害に備えるなら、それぞれを複数台構成にする方法もある。一台が止まっても、別の一台で動き続けられるようにする「冗長構成」だ。
ただし、複数の仮想マシンが同じ物理サーバーやネットワークを使っていれば、その部分が故障したときには両方とも止まる可能性がある。
AIに設計を依頼すると、このような冗長構成も提案される。
なるほど。障害対策としては合理的だ。しかし、ここでも疑問が出てくる。社員20名が利用する仕組みに、どこまでの冗長化が必要なのだろう。
一時間停止すると業務に大きな影響があるのか。
それとも、半日程度なら手作業で対応できるのか。
既存の仮想化基盤には、十分な空きリソース（CPUやメモリ、ストレージの余裕）があるのか。
バックアップや監視は、すでに用意されているのか。
こうした条件によって、必要な構成は変わる。
最初は小規模な構成で始め、利用状況を見ながら拡張する方が合理的な場合もある。
一方、重要な業務に組み込むなら、初期段階から高い可用性（止まらずに使い続けられること）が必要になるかもしれない。
つまり、サーバーを何台用意するかは、単純に利用人数だけで決まるものではない。
ここまでをAIにまとめてもらった
こうした条件をもとに、AIへシステムの設計書を作るよう依頼してみた。
認証・認可、情報漏洩対策、監査、サーバー構成、費用、運用体制。
これらを含めた構成案を、図解付きで作成するように指示した。
すると、約14分で7ページのPDFが完成した。
構成図には、AIサービスと社内サーバーの接続が描かれている。
認証基盤、権限管理、情報漏洩対策、監査ログの収集先も整理されている。
さらに、仮想マシンの台数や必要なリソース、導入スケジュール、運用担当者の役割まで記載されていた。
設計資料としては、なかなかの出来だった。
しかし、ここまで技術を一つずつ考えてきた後で資料を見ると、別のことが気になった。
この会社に必要な構成要素は、本当にここまで多いのだろうか。
設計書が完成しても、設計が終わったわけではない
例えば、AIが高機能な法人向けサービスを推奨していたとする。組織管理や監査機能が充実しているからだ。
しかし、その会社で必要な監査要件が分からなければ、より安価なプランでは不足するのか判断できない。同じことは、DLPや冗長化、監視基盤にも言える。
必要な技術として説明できることと、その会社に導入すべき技術であることは違う。
AIは一般的に妥当な技術を組み合わせ、整合性のある構成案を作ることができる。しかし、実際の会社の条件を確認していなければ、その構成を採用してよいかどうかは決められない。
振り返ってみると、ここまでの章で挙げた問いの多くは、まだ答えが出ていなかった。
共通の認証基盤はあるのか。どの情報を守るのか。どのくらい止まったら困るのか。それでも、設計書は完成していた。条件が決まっていない部分があっても、一般的に合理的な前提を置けば、構成案は作れるからだ。
そして、完成度の高い資料ほど、どこが確認済みで、どこが仮の前提なのかが見えにくくなることがある。
これは、AIに限った話ではない。人間が設計する場合にも、未確認の前提を置いたまま資料を仕上げてしまうことはある。
ただ、AIによって資料が短時間でできるようになると、前提を確かめるより先に資料のほうが完成してしまう。
そこで、完成した設計書をもう一度見直すことになった。
なぜ、この機能が必要なのか
既存の仕組みでは代用できないのか
その機能を外すと、何が起きるのか
どの条件が変われば、別の構成を選ぶのか
完成した資料を、一つずつ分解していく。
考えてみれば、少し不思議な作業だ。
AIは14分で設計書を完成させた。
その後、人間はその設計書に書かれたものが本当に必要なのかを考え始めた。
最初から選別しながら作った方が早かったのではないか
今回、AIに一括で設計書を作らせる前に、別の方法でも構成を考えていた。
AIとの対話を通じて、一つずつ技術を確認していく方法だ。
まず、何を実現したいのかを考える。
次に、そのために必要な仕組みを確認する。
別の方法があれば比較する。
不要だと判断したものは外す。
分からないものは保留する。
そして、残った要素を組み合わせていく。
この方法なら、構成案を作る過程で、自分自身の理解も変わっていく。
最初は必要だと思っていたものが、実は不要かもしれないと分かる。
逆に、考慮していなかった要素が必要になることもある。
もちろん、対話を続ければ必ず正しい設計になるわけではない。
AIの説明が間違っていることもあれば、こちらの前提が間違っていることもある。
実際の業務やシステムを確認しなければ、判断できないことも多い。それでも、対話の中で何を採用し、何を外したのかを追跡できるという利点がある。
一括生成された設計書でも、判断の根拠を確認することはできる。
ただし、完成した資料を後から分解するのであれば、最初から選別しながら作る方が効率的な場合もあるのではないだろうか。
AI時代の設計者は、何をするのだろう
今回の出来事で、AIの性能向上を実感した。
14分で7ページの設計書を作る。
少し前なら、相当な作業時間が必要だったはずだ。しかし、設計書を作れることと、その設計を採用できることは同じではない。
設計には、技術を知ることだけでなく、現実の条件を確認することが必要になる。
何を作るのか
なぜ作るのか
どこまで作るのか
そして、何を作らないのか
AIが技術を組み合わせる能力を高めていくほど、こうした判断の重要性が増すのかもしれない。
ただし、これもまだ仮説だ。
AIがさらに進歩すれば、必要な条件を自ら質問し、構成要素を選別する能力も向上するだろう。
そうなったとき、人間の役割がどう変わるのかは分からない。
それでも、現時点で一つ言えそうなことがある。
AIが設計書を作れるようになったからといって、設計する理由まで自動的に決まるわけではない。
そして、今回の話には少し皮肉な結末がある。
AIが14分で立派な設計書を作ってくれた。
その資料を見て私は考えた。この構成、本当に必要なのだろうか。
結局、設計書を作る前に考えるべきことを、設計書が完成してから考え始めていた。
AIは作り方を教えてくれた。しかし、この会社で何を作らなくてよいのかは、まだ決まっていなかった。
