政府がAI幕僚を導入する際のセキュリティ・監査・オンプレミス要件

機関がAI幕僚を評価する際、機能デモが最後の関門になることはほとんどありません——セキュリティ審査こそが関門です。データは国外に送られないか？誰が何を見られるのか？AIの出力は毎回記録され確認できるのか？システム全体を機関自身のサーバールームに置けるのか？本記事は、政府がAI幕僚システムを導入する際の6大セキュリティ要件、監査設計、オンプレミス展開オプションを整理し、調達仕様書にそのまま使えるチェックリストを提供します。

まず全体像から:政府AIセキュリティの規制マップ

AI参謀を導入する行政機関が向き合うのは単一の法規ではなく、四層の規制の重なりです。サイバーセキュリティ管理法が定める機関のセキュリティ責任等級とシステム防護基準、個人情報保護法が個人データの収集・利用に課す境界線、行政院が公務機関の生成AI利用に向けて発表した参考ガイドライン、そして政府調達と共同調達契約がサプライチェーンセキュリティとベンダー資格に課す要件です。本記事で後述する六つの要求事項は、そのほぼすべてがこの四層のいずれかに対応します。仕様書に書き込める条項の多くは、ベンダーが独自に約束する品質保証ではなく、規制がすでに求めている事項なのです。

以下はあくまで一般的な枠組みの説明であり、担当者が全体像を把握する助けとするものです。実際の適用範囲、作業要件、対応事項については、主務機関の最新の公告、貴機関のセキュリティ責任等級、そして機関のセキュリティ担当者・政風部門の判断に従ってください。

この四層の規制に共通する精神は、実は「制御可能」と「追跡可能」の二つに尽きます。制御可能とは、データがどこにあり、誰が処理し、誰が閲覧できるかを機関が常に説明できることです。追跡可能とは、後から問われたときに、機関が裏付けとなる記録を提示できることです。この点を理解すれば、後述する六つの要求事項はベンダーの機能セールストークではなく、制御可能性と追跡可能性をシステム設計に落とし込む具体的な方法だと分かります。

1. データ主権:データを国外に出さないことが最低ライン

多くのパブリッククラウド生成AIサービスの推論は国外のデータセンターで行われます。これは政府業務にとって根本的な障害です——公務情報が一度国外サービスに入れば、機関はデータの流れへのコントロールを失います。コンプライアンスに適合するAI幕僚システムは、データホスティングとモデル推論の両方が台湾国内にあること、ベンダーがISO 27001認証を持つこと、データ転送がTLS 1.2以上の暗号化を使うことを保証すべきです。調達仕様書には「データの保存と処理は台湾国内から出てはならない」と明記すべきです。

仕様書には次のように書けます:本案に関するすべてのデータの保管、処理及びモデル推論は台湾国内で完結させるものとし、いかなる形式であれ海外のデータセンターや海外のAIサービスに送信してはならない。ベンダーは入札書類にデータセンターの所在地に関する説明とISO 27001認証書類を添付すること。第三者コンポーネントや委託処理が関わる場合は、処理者、処理場所及びデータ項目を逐一明記し、変更が生じる際は事前に機関の同意を得ること。この一文を仕様に盛り込むことで、入札段階で要件を満たさない提案をふるいにかけられ、審査段階になってからアーキテクチャを変更できないと判明する事態を避けられます。

2. 展開オプション:クラウド・プライベートクラウド・オンプレミスの選択

業務の機密度に応じて、展開オプションは低い順に:台湾国内クラウド（公開世論中心のモニタリング業務に適する）、政府プライベートクラウド、そして完全オンプレミス——システムもモデルも機関自身のサーバールームで稼働し、モデル推論さえ外部接続を必要としません。内部公文書や機密データを統合するAI幕僚は、最初からオンプレミスを目標アーキテクチャとすることを推奨します。外部世論収集層はクラウドに残し、「外はクラウド・内はオンプレミス」のハイブリッド構造で、データカバレッジとセキュリティ境界を両立させます。

外部クラウド・内部オンプレミスを推奨アーキテクチャとする理由はシンプルです。外部の世論データは量が多く発生源も頻繁に変わるため、クラウドでの収集とクレンジングが最も効率的であり、そもそもこれらのデータは公開情報です。一方、内部の公文書や分析判断は機関の外に出す必要が一切ありません。両者を明確な境界で分離すれば、機関が対外的に説明すべきことは一つだけになります。境界を越えるのはどのデータで、どちらの方向に流れるのか、という点です。これはすべてをクラウドに載せる、あるいはすべてをオンプレミスに詰め込むよりも、審査の際にかえって説明しやすくなります。

オンプレミスモデルの選び方:台湾の行政機関が使えるオープンソースの選択肢

オンプレミス化を決めた後の次の課題は、モデルをどこから調達するかです。台湾の行政機関が現実的に検討できるオープンソースまたはオープンウェイトモデルは、現時点でTAIDE、Gemma 4 31B、GPT-OSS、Mistralシリーズの四種類が中心です。選定基準はリーダーボードのスコアではなく、次の三点です。ライセンス条件が機関内での利用とカスタマイズを許可しているか、繁体字中国語と公文書特有の言い回しをどの程度扱えるか、そして1枚または少数の上位GPUで動作するかどうかです。多くの機関にとって最初のオンプレミスシステムはデータセンターと予算の制約を受けるため、モデルの性能よりもハードウェアの実現可能性が先に決定要因となることが少なくありません。

先にはっきり述べておくべきレッドラインがあります。中国で開発されたモデル（Qwen、DeepSeekなど）は、オンプレミスで完全に外部接続を遮断した形で運用したとしても、台湾の行政機関や規制対象企業では選択肢に含めることを推奨しません。理由は三つあります。データ主権とモデルの原産国に関する懸念、政府調達における製品の調達元とサプライチェーンセキュリティの制限、そして今後の保守やウェイト更新のルートも海外に由来する点です。実務上、この種の選択肢は機関のセキュリティ審査を通過できないことが多く、選考の後半で差し戻されるよりは、選定の第一段階で除外しておく方が賢明です。

能力差については、オンプレミスのオープンソースモデルとGPT-5.6、Claude Fable 5、Gemini 3といった最先端のクラウドモデルとの間には、確かにまだ差があります。しかしこの差は公務のユースケースではアーキテクチャで補うことができます。機関の法規、過去の公文書、会議記録をナレッジベースとして構築し、RAGアーキテクチャによってモデルが毎回検索した原文に基づいて回答するようにすれば、回答の質はモデル自体がどれだけ記憶しているかではなく、ナレッジベースの整備状況によって決まります。つまり、力を注ぐべきはモデルのリーダーボード争いではなく、データガバナンスなのです。台湾企業向けLLM選定ガイド には各モデルのライセンス条件とハードウェア要件についてより詳細な比較があり、選定会議の参考資料として活用できます。

3. アクセス制御:誰が何を見られ、何を尋ねられるか

AI幕僚が集約する情報の機密度は一様ではありません:公開世論は誰でも見られますが、質疑論戦資料は幕僚サークルに限定され、個別案件に関わる内部分析は特定レベルのみアクセス可能です。システムはロールベースアクセス制御(RBAC)をサポートすべきです——職務レベルと業務分担に応じてデータの可視範囲と機能権限を設定し、多要素認証(MFA)を組み合わせます。同じシステムの中で、首長、部局長、担当者が見る内容と実行できるクエリは異なるべきです。

権限マトリクスは要件ヒアリングの段階で作成し、仕様書の附属資料とすることをお勧めします。一般的な機関の組織構成を例にすると、閲覧範囲はおおよそ次のようになります。

• 首長:機関全体の議題概観、局処横断のリスク集約、すべての早期警告・分析報告
• 局処主管:自局処の業務に関連する議題、所属職員への指示事項と進捗
• 幕僚圏:質疑応答の攻防資料、答弁ドラフト、局処横断の議題の文脈。ただし個別案件の機密内容は含まない
• 担当者:自身が担当する議題の元データと分析結果。照会は可能だが機関全体の帳票をエクスポートすることはできない

4. 使用記録:モデルの行動に痕跡を残す

生成AIは新しい監査対象を持ち込みました:モデル自身の行動です。コンプライアンスに適合するシステムは、誰がいつ何を照会したか、モデルがどの資料を引用して応答を生成したか、アラートとブリーフィングが誰に送られたかを保存すべきです。これらの記録には2つの用途があります——セキュリティ事案の事後調査と、「AIが不適切に使われていないか」という監督上の疑問への回答です。使用記録のないAIシステムは、政府環境では監査の死角に等しいのです。

仕様書には保存すべき項目を逐一列挙し、ベンダーが「システムにはログ機能がある」の一言で済ませることのないようにすべきです。最低限、次の項目を含めることを推奨します。

• 照会者:アカウント、所属部署、当時の役割権限
• 照会時刻:開始・終了のタイムスタンプと発信元のネットワークセグメント
• 照会内容:利用者が入力した質問、または設定したモニタリング条件
• モデル引用データ:今回の回答で検索・取得された文書、段落、または世論ソースの一覧
• 送信対象:早期警告や簡報の受信者、送信チャネル、送信時刻

これらの記録には保存期限とアクセス権限を設定すべきです。記録を閲覧できる人自身の行動も記録に残す必要があります。そうでなければ、監査記録そのものが新たな漏洩経路になりかねません。

5. 出力監査:AIが書いた部分と人が直した部分を分離できること

プレスリリースや答弁資料がAI支援で作成される場合、機関は「どこがAIの執筆か、誰が修正したか、誰が承認したか」に答えられなければなりません。システムは完全なバージョン証跡を保持すべきです:AI生成版、人による修正版、修正者、承認者、引用資料、生成時刻。これは監査要件であるだけでなく、担当者を守る設計でもあります——争議が生じた際、人によるゲートキーピングが確かに行われたことを明確に立証できるのです。

完全なバージョン履歴には少なくとも次の項目を含み、文書ごとに個別にエクスポートできるようにすべきです。

• AIによる初期生成バージョンと生成時刻
• 人による修正のたびのバージョン、修正者、修正時刻
• 各バージョン間の差分比較。どの段落が書き換えられたかが分かる
• 承認者、承認時刻、承認された最終バージョン
• 今回の出力が引用したデータソースの一覧

6. 出典追跡可能性:すべての結論に出所を

セキュリティ審査はデータがどう入り、どう保護されるかに注目します。説明責任のメカニズムは結論がどう生成されるかに注目します。AI幕僚のすべての分析と提言は原資料に遡れるべきです——ニュース原文、SNS投稿、公文書、会議録——そしてインターフェース上で確認済みの事実、世論の観察、AIの推論を区別すべきです。追跡可能性は調達の必須条件とすべきです:出所を説明できない出力は、政府のプロセスにおいて正式な価値を持ちません。

検収時には抜き取り検査によって、この要求が実際に実装されているかを確認できます。機関の担当者がシステムが生成した分析報告の中から任意の結論部分を指定し、その場で元データまで遡って、出典が存在すること、内容が一致すること、時期が正確であることを確認させます。指定した箇所がAIによる推論である場合は、システムはそれを事実ではなく推論として明確に表示すべきです。抜き取り検査の設問は機関がその場で出題し、合格基準を検収項目に書き込むことで、事前に機能説明書を読むよりもはるかに実際の使い勝手を反映できます。

セキュリティ審査を通過するには:4ステップの準備プロセス

セキュリティ審査が長引く原因の多くは、システムが基準を満たしていないからではなく、準備の順序を誤っているからです。システムを完成させてから文書を後追いで整えようとすると、アーキテクチャがもはや調整できないことに気づくケースが少なくありません。審査は四段階の準備プロセスとして捉えることをお勧めします。自己評価と等級判定、文書準備、審査と補正、稼働後の継続的な監査です。最初の二段階は契約締結前に着手すべきであり、四段階目は保守契約の条項に書き込んでおかなければ、稼働後に管理が行き届かなくなります。

一、自己評価と等級判定:まず自分がクリアすべき基準を確認する

最初のステップはベンダー探しではなく、機関のセキュリティ担当者が二つのことを確認することです。本システムに該当するシステム防護等級、そしてシステムに入力されるデータの機密分類です。同じ「AI参謀」と呼ばれていても、公開の世論モニタリングのみを行う場合と、内部の人事・個別案件データを統合する場合とでは、求められる要件が大きく異なります。取り込む予定のデータを種類ごとに列挙し（公開ニュース、SNS投稿、内部公文書、会議記録、個別案件データ）、それぞれの機密等級と個人データを含むかどうかを明記します。この一覧表がデプロイモデルを外部クラウド・内部オンプレミスのハイブリッドにするか完全オンプレミスにするかを直接左右し、後続文書の深度も決定します。このステップを飛ばすことは、機関のリスク許容度をベンダーに決めさせることに等しくなります。

二、文書準備:美しく書くことより、アーキテクチャを明確に説明することが重要

文書の核心となるのは、データの流れを明示したシステム構成図です。各データがどこから来て、どのコンポーネントを経由し、どのホストに保存され、誰がアクセスできるかを、矢印の方向と保存場所とともに明確に示す必要があります。その他によく求められる文書には、ベンダーのISO 27001証明書、個人データの棚卸しと法令遵守に関する説明、権限マトリクス、バックアップと事業継続計画、脆弱性スキャンまたは侵入テストの報告書などがあります。政府への導入実績があるベンダーは通常、流用可能な文書テンプレートを備えているため、機関は本案固有の差異部分だけを調整すればよく、往復のやり取りをかなり削減できます。

三、審査と補正:指摘事項をToDoリストに集約する

審査コメントの多くは、いくつか決まった方向に集中します。データが外部に流出する可能性はないか、権限の切り分けが確実に実施されているか、記録は閲覧できるか、ベンダー担当者の運用アクセスがどう管理されているか、といった点です。コメントを受け取ったら、機関の担当者が一つのToDoリストに統合し、それぞれについて責任主体が機関かベンダーか、完了予定時期、裏付け文書を明記することをお勧めします。往復するメールにコメントを散在させないようにします。同じラウンドで問題を出し切り、補正も完了させる方が、複数回に分けて小出しに対応するよりもたいてい早く済みます。

四、稼働後:年次監査と記録閲覧訓練

審査を通過することは、あくまで出発点にすぎません。システムが稼働を開始した後は、機関の年次セキュリティ監査の対象に組み込み、人事異動に応じて権限が更新されているか、離職・異動した職員のアカウントが確実に無効化されているか、バックアップが復元可能かを定期的に確認すべきです。また、年に一度は記録閲覧訓練を実施することをお勧めします。あるAI支援による出力データについて誰かが疑義を呈したと想定し、機関が合理的な時間内に完全な照会記録とバージョン履歴を提示できるかを確認するものです。一度訓練を行って初めて、記録が本当に使えるものなのか、それとも存在するだけのものなのかが分かります。関連する要求事項は保守契約にも書き込み、ベンダーの協力義務を明記すべきです。

調達仕様チェックリスト

• データ保存とモデル推論がともに台湾国内、ベンダーはISO 27001認証を保有
• 完全オンプレミス展開オプション、または「外部収集はクラウド+内部ナレッジはオンプレミス」のハイブリッド構造を提供
• RBACロール権限、MFA多要素認証をサポートし、権限変更の記録を保持
• 完全なクエリ記録とモデル使用記録を保存し、セキュリティ監査で閲覧可能
• AI出力のバージョン証跡を保持:生成版・修正版・修正者・承認者・時刻
• すべての結論に原資料リンクを付け、インターフェースで事実・観察・AI推論を区別
• 個人情報の取り扱いは個人情報保護法に準拠:公開コンテンツのみ収集し、統計化して表示