情報システム部門への説明

2026年8月21日 GenAI活用スキル向上支援 第3回／株式会社ギブリー 安田 光喜

---

1. この資料の使い方

情報システム部門に持っていくのは、作ったアプリそのものではありません。3点だけです。

1. /secure が出力した 点検レポート.md。第2章の表に、そのアプリが何を送り何を保存するかが書いてあります
2. app.html そのもの。1ファイルなので、担当者はテキストエディタで最初から最後まで読めます
3. この資料の第2章の表。ツール側の契約・保持期間・到達範囲を、公式ドキュメントの記述で埋めたものです

順番が大事です。先に点検レポートを渡し、質問が出てからこの資料を出してください。最初から全部を出すと、審査する側は「何かを押し切りに来た」と受け取ります。

審査の実務は、ツールが安全かどうかを見ていません。Anthropic が2026年7月17日に公開した CISO's guide to agentic AI は、判断の軸を4つの問いに整理しています。取り込む非信頼コンテンツは何か。どの操作を誰の身元で実行できるか。逸脱したときの影響範囲はどこまでか。その行動を監視系で観測できるか（https://claude.com/blog/ciso-guide-to-agentic-ai ）。

同じ文書に、情報システム部門の仕事の定義が書かれています。ゼロリスクにすることではなく、リスクを可視化して境界を引き、組織として意図的に受容できる状態にすること。この言い方を借りると、話が早く進みます。

想定される持ち込み単位は [15min] 程度の相談です。決裁を取りに行く場ではありません。「これを1か月、自分だけで使ってよいか」を聞くところから始めてください。

なお、社内で承認されている生成AIツールが Claude Code 以外である場合も、第2章の7問はそのまま使えます。答えの中身を、そのツールの公式ドキュメントで埋め替えてください。問いの構造はベンダーに依存しません。

---

2. 情報システム部門が最初に聞く7つの質問

表に入りきらない3点

保持期間で見落とされるのが /feedback です。プランに関係なく、会話履歴とコードのコピーが送信され5年保存されます。既定は現在のセッションのみですが、同一プロジェクトの過去24時間分・7日分を含める選択肢もあります。演習フォルダの設定には DISABLE_FEEDBACK_COMMAND=1 を最初から入れてあります。あわせて、セッション品質アンケートの後に出る「トランスクリプトを見てよいか」に Yes と答えると、会話とサブエージェントのログとローカルのセッションログが送信され最大6か月保持されます。既知のAPIキーとトークンのパターンは伏せられますが、ソースコードとファイル内容はそのまま上がります。

権限の範囲は、.gitignore の話を先に出すと通りが良くなります。The Register が2026年1月28日に検証しています。.env を書いた .claudeignore を置いた状態で Claude Code v2.1.12 に読ませたところ普通に読み、.gitignore で除外したプロジェクトでも「このファイルには認証情報が含まれます」という警告を添えたうえで、内容をコンソールに出力しました（https://www.theregister.com/2026/01/28/claude_code_ai_secrets_files/ ）。この事実を先に自分から言うと、審査側の探索コストが下がります。

ネットワークの穴も自分から言ってください。2つあります。WebFetch は取得前に対象のホスト名だけを api.anthropic.com に送って安全性ブロックリストと照合します。この通信は非必須トラフィックの一括停止では止まらず、skipWebFetchPreflight: true を別途設定する必要があります。もう1つ、WebFetch を deny しても Bash が許可されていれば curl と wget で任意のURLに到達できます。公式ドキュメント自身がこの穴を指摘し、OSレベルのサンドボックスとドメイン許可リスト（sandbox.network.allowedDomains）で塞ぐよう書いています。

認証取得状況

Claude Code 公式ドキュメントの Security ページは、参照先として SOC 2 Type 2 レポートと ISO 27001 証明書を名指しし、取得窓口を Anthropic Trust Center としています（https://code.claude.com/docs/en/security ）。

ISO/IEC 42001（AIマネジメントシステム）の取得状況は、この資料の作成時点で一次確認が取れていません。要確認です。確認先は https://trust.anthropic.com です。

参考として、日本の ISO/IEC 42001 認証取得組織は2026年8月5日時点で10組織です（ISMS-AC の認証組織検索 https://isms.jp/aims/lst/ind/ ）。認定開始が2025年7月8日、最初の認定認証機関の誕生が2026年1月14日という段階なので、日本ではまだ足切り条件として機能しません。

---

3. 単一HTMLという形が審査を通しやすい理由

ここが本題です。技術の選択ではなく、審査の設計として効きます。

外部通信なし

作ったアプリは、通信を行う記述を1行も持ちません。fetch XMLHttpRequest WebSocket navigator.sendBeacon のいずれも0件。外部から読み込むものもありません。<script src="http <link href="http @import url(http も0件。<form action= もありません。/secure の点検項目 A1 から A5 が、この5つを実際に検索して確認します。

意味するところは、審査側にとっての「データの行き先」が空集合になることです。プロキシの例外申請が要りません。宛先ドメインの許可リストに追加する行がありません。通信ログの監視対象が増えません。情報システム部門が普段やっている作業のうち、外部SaaS導入で最も重いものが丸ごと発生しない構造です。

外部の画像を読み込まない点も効きます。<img src="http が1件でもあると、画像を置いているサーバーに「誰がいつこのアプリを開いたか」が記録されます。これは通信でありアクセスログです。0件なら、その論点も消えます。

保存はブラウザ内

データは localStorage に保存されます。保存先は、そのPCの、そのブラウザのプロファイルの中だけです。別のPCからも、同じPCの別ブラウザからも見えません。サーバーもデータベースもありません。

サーバーが存在しないことで、非エンジニアが作るアプリの事故のうち3類型が構造的に成立しなくなります。

OWASP Top 10:2025 の第1位は引き続き Broken Access Control です（https://owasp.org/Top10/2025/ ）。認可の対象になるサーバーが存在しないアプリでは、この1位が発生しません。

Tea アプリについては、原因がバイブコーディングだと断定された事実はありません。Bloomberg Law も「疑惑」という語を使っています。正確な言い方は「AI起因と断定できないが、AI生成コードが量産する失敗と同型」です。情報システム部門にはこの言い方で出してください。断定して出すと、他の説明の信頼度まで落ちます。

依存ゼロ

外部ライブラリを読み込みません。CDN も使いません。package.json がなく、npm install を実行しません。

ここが、審査で最も効く割に説明されない部分です。ソフトウェアサプライチェーンの汚染は、2026年の OWASP Top 10 で A03 として新設されるほど中心的な論点になりました。2026年の Shai-Hulud 系ワームは npm と PyPI の172パッケージ、404バージョンを汚染しています。読み込むものがなければ、この面が丸ごと存在しません。

CDN の1行がどれだけ重いかは、polyfill.io の事例が示します。2024年2月に中国企業がドメインと GitHub アカウントを取得し、6月25日時点で10万を超えるサイトに悪性コードを配っていました。影響を受けたサイトに JSTOR、Intuit、World Economic Forum が含まれます（https://sansec.io/research/polyfill-supply-chain-attack ）。<script src="https://cdn..."> を1行入れることは、他人のサーバーに自分の画面の実行権を渡すことです。

依存がゼロなら、Dependabot も npm audit も要りません。脆弱性が公表されるたびに影響調査をする対象がありません。導入後の運用コストが、審査の時点でゼロだと言えます。

読める

3点に加えて、審査側にとって実務的に効くのが監査可能性です。

成果物は1ファイル、数百行です。担当者はブラウザで Ctrl+U を押すか、テキストエディタで開けば、最初から最後まで全部読めます。Excel マクロは VBA エディタを開かないと中身が見えず、シートに埋まった数式は目視で追えませんでした。HTML は隠れません。

差分も1ファイルです。改修したら、前の版と新しい版を並べれば何が変わったか分かります。EY Japan が2012年に整理したスプレッドシート管理7点のうち「計算式・マクロの正確性確認」と「操作仕様・処理手順の文書化」が、単一HTMLでは構造的に楽になります。

消えないもの

正直に1つだけ残ります。クロスサイトスクリプティングです。

利用者が入力した文字を innerHTML にそのまま入れる書き方を、AIは平気で出します。Veracode の2026年春の再評価では、CWE-80 を安全に書けたのは15%でした（https://www.veracode.com/blog/spring-2026-genai-code-security/ ）。2025年版の調査では、該当サンプルの86%で防御に失敗しています。

だから /secure の点検項目 B1 は innerHTML insertAdjacentHTML outerHTML を機械的に探し、見つかったら変数をたどって利用者入力が入る経路があるかを確認します。textContent への代入か、エスケープ処理が入っていれば問題なしと判定します。この1項目のために点検を回している、と言っても言い過ぎではありません。

---

4. これでも残るリスク

第3章で消えるものを並べたので、消えないものを同じ密度で書きます。この章を省いた資料は、情報システム部門に読まれた時点で信用を失います。

配ったファイルは中身が読める

app.html は1ファイルです。Slack に貼れば、中身ごと出ていきます。メールに添付すれば、相手のPCに残ります。

パスワードや認証キーを書き込む用途には使えません。防御は運用ルールではなく、ファイルに入れないことだけです。クライアント名、案件名、未公開の数値をコードやコメントに書かせない。これが唯一の対策です。

共用PCも同じです。localStorage に入れたデータは、そのブラウザを次に使う人が読めます。OWASP の HTML5 Security Cheat Sheet は「認証が前提となる場面で localStorage に機微情報を置くな」「セッション識別子を置くな」と明記しています。

複数人で同じデータを見られない

保存先がブラウザ内であることの裏返しです。同じファイルを2人に配ると、データは2つに分かれます。合流しません。

全員で1つの表を共有したい要求が出た瞬間、この作り方では対応できません。そのときは作り直しになります。作り直しになる前提で、最初から共有が必要な業務には使わない判断が要ります。

作った本人しか直せない

過去のEUCで最も繰り返された失敗です。RPA では野良ロボットと呼ばれました。作成者不明、仕様書なし、止められないロボットが残ります。

EY Japan が2017年に挙げたRPA統制の3リスクのうち、2つ目が「業務知識を有する担当社員が少なくなり、緊急時への対応が困難になるリスク」です（https://www.ey.com/ja_jp/technical/library/info-sensor/2017/info-sensor-2017-10-09 ）。

AI生成アプリでは、これが過去より悪化します。Excel の数式は、作った本人も監査人も読めました。生成されたコードは、作った本人が読めません。読解可能性の非対称が、最大の断絶です。

制度変更で静かに間違う

EY のRPA統制3リスクの3つ目です。業務プロセスが変わったのにロジックが更新されず、誤った業務が継続的に実施される。

止まらないから誰も気づきません。誤った処理を毎日正確に繰り返します。

この類型が金額でどこまで行くかは、スプレッドシートの実例が示しています。

Reinhart-Rogoff が示すのは、金額ではなく別のことです。誤りが検証されないまま権威になる。これがEUCの本当の怖さです。

---

5. 統制のかけ方

過去に3回同じことが起きています。Excelマクロ、Access、RPA。三度とも失敗の型が同じでした。台帳がない、責任者がいない、検証されない、作った人が異動する。

先に事実を1つ置きます。金融庁の「財務報告に係る内部統制の評価及び監査の基準並びに実施基準」（企業会計審議会、2023年4月7日改訂）の本文には、EUC もエンドユーザーコンピューティング もスプレッドシート も表計算 も一度も出てきません。PDF全文を機械検索して確認しました（https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html ）。

基準が定めているのは、ITへの対応を「IT環境への対応」と「ITの利用及び統制」に分け、統制活動を全般統制と業務処理統制の2つに分ける枠組みだけです。EUC統制は明文規定ではなく、この枠組みを表計算ファイルに当てはめた実務解釈として存在してきました。

つまり、新しい統制を発明する必要がありません。既存の枠組みに乗せるだけです。

5点セット

過去3回で実際に効いたものだけ残すと5つになります。

EY Japan が2012年に整理したスプレッドシート管理7点（台帳作成、計算式の正確性確認、アクセスコントロール、改ざん防止、バックアップ、作成時と変更時の承認、操作仕様の文書化）と、この5点はほぼ重なります（https://www.ey.com/ja_jp/technical/corporate-accounting/commentary/internal-control/commentary-internal-control-2012-04-05 ）。既存の内部統制の言葉で説明できるということです。

昇格ゲート

5点セットを全部に掛けると、全部が形骸化します。強度を3段に分けてください。

境界を決めるのが経営の仕事、3段目の中身を決めるのが情報システム部門の仕事です。この分担を混ぜると、情報システム部門が1段目まで止めにいって普及が止まります。RPAで実際に起きたのがこれです。

決算数値に触れた瞬間、それはIT業務処理統制とIT全般統制の評価対象になります。触れないうちは自由に作れます。この線を最初に引いておけば、監査対応の話とバイブコーディング推進の話が衝突しません。

禁止すると台帳から消えるだけ

EUCもRPAも、禁止した会社より登録させた会社のほうが結果的に事故が少なくなっています。禁止しても作ること自体は止まりません。台帳から消えるだけです。

数字があります。IBM の Cost of a Data Breach Report 2025 は、シャドーAIの利用水準が高い組織で平均67万ドル侵害コストが高く、5社に1社がシャドーAIに起因する侵害を報告したと公表しました。AIを狙われた侵害を報告した組織の97%はAIのアクセス制御を持たず、侵害を受けた組織の63%はAIガバナンス方針を持たないか策定中でした（https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls ）。

2026年版（2026年7月29日公表、602組織が対象）では平均侵害コストが499万ドル、悪意ある侵害の4件に1件がAIを用いたもので前年比56%増、AIを用いた侵害の平均コストは約600万ドルと全体平均より約100万ドル高い、という結果が出ています。

「禁止すれば安全」の逆を示す数字として、この2つは審査の場で使えます。

---

6. 会社として決めておくこと

技術の話ではありません。誰が判を押すかの話です。5行で決まります。

この表を先に埋めておくと、審査の場で「誰が責任を持つのか」という質問に即答できます。答えられないと、そこで止まります。

個人PCで社内ネットワークに接続しない形態については、追加で1つ決めてください。この形態は、統制の効き方が特殊です。

肯定材料。社内システムへの到達経路が物理的に存在しないので、権限昇格と横展開のリスクがほぼ消えます。

否定材料のほうが本質的です。統制チャネルが1本も刺さりません。管理設定（macOS は /Library/Application Support/ClaudeCode/managed-settings.json、Windows は C:\Program Files\ClaudeCode\managed-settings.json）は管理者権限で配布して初めて意味を持ちますが、個人PCには配布できません。forceLoginOrgUUID による組織外資格情報の遮断も、OpenTelemetry による組織コレクタへのログ送信も、端末を管理下に置けなければ効きません。加えて、端末側の平文ログが30日残る先が、会社が消去を命じられない私物になります。

シャドーITとの境界は、ここで決まります。私物端末での利用が黙認や自己判断で始まっていれば、それはシャドーITです。対象者、期間、扱ってよいデータ区分、終了後の消去手順を文書で確定し、経営が承認していれば、統制の効かない例外として意図的に受容した状態になります。差は技術ではなく、承認記録と期限の有無だけです。

したがって、情報システム部門への説明で使う言い方はこうなります。私物PCだから安全、ではありません。私物PCだから統制が効かないと明示したうえで、期限を切って受容する。

経営責任の観点も1行だけ添えておきます。日本には「取締役のAI監督義務」を定めた条文がまだありません。効いてくるのは会社法362条4項6号と会社法施行規則100条の内部統制システム構築義務です。判例は大和銀行株主代表訴訟（大阪地判 平成12年9月20日）と日本システム技術事件（最判 平成21年7月9日）で、後者は通常想定される不正を防止しうる体制を整えていれば責任を負わないとしました。問われるのは結果ではなく体制です。取締役会でAI利用のリスクと統制が審議され、議事録に残っているかどうかが分かれ目になります。

---

7. 情報システム部門に出してはいけない材料

逆効果になるものがあります。理由つきで挙げます。

効く材料は逆です。契約条項の条番号、保持日数の数字、設定キー名とファイルパス、/status コマンドで管理設定の適用状況を確認する手順。誰が何を設定すれば止まるかを具体名で言えること。

もう1つ効くのが、自分から限界を先に出すことです。ZDR が標準機能でない点、私物PCには管理設定が届かない点、WebFetch のプリフライトは非必須トラフィック停止でも止まらない点。提案側から言うと、審査側の探索コストが下がって話が速くなります。

---

8. そのまま使えるメール文面

試したい段階

件名: 生成AIで作った業務ツールの取り扱いについてご相談

○○部 ○○様

お疲れさまです。○○部の○○です。

先日の研修で、生成AIを使って業務用の小さなツールを作りました。まだ自分ひとりで使う段階ですが、進める前に一度ご相談させてください。

作ったものは、HTMLファイル1本です。次の3点を確認済みです。

• 外部と通信する記述が1件もありません（fetch XMLHttpRequest WebSocket sendBeacon すべて0件）
• 外部のライブラリ、フォント、画像を1件も読み込んでいません
• データはブラウザ内にのみ保存され、そのPCの外に出ません

点検レポートを添付します。どこに何を送るか、どこに何を保存するか、誰が見られるか、やめたいときにどう消すかの4点に答える形になっています。

ご相談したいのは1点だけです。まず1か月、私ひとりで使ってよいでしょうか。使い続けられるようなら、そのときに改めて配布の可否をご相談します。

なお、この点検レポートは作ったAI自身が自分の成果物を点検したものです。人の目を1度入れていただけると助かります。

[15min] ほどお時間をいただければ、画面をお見せしながらご説明します。

○○

広げたい段階

件名: 内製ツールの部門内配布についてのご相談（台帳登録あわせて）

○○部 ○○様

お疲れさまです。○○部の○○です。

○月にご相談した業務ツールを1か月使い続けました。週○回、1回あたり約○分の作業が置き換わっています。同じ業務を担当している○名から使いたいという声が出たため、部門内での配布についてご相談させてください。

現状は次のとおりです。

• 形式: HTMLファイル1本。外部との通信なし、外部ライブラリなし、データはブラウザ内のみ
• 扱うデータ: ○○（クライアント名、未公開の数値、個人情報は含みません）
• 配布範囲: ○○部○○チームの○名
• 想定利用期間: ○年○月まで。延長時は改めて棚卸しをお願いします

あわせて、台帳登録をお願いしたく、次の項目をご用意しました。

決算数値には触れません。顧客への提出物にも使いません。この2点が変わる場合は、事前に改めてご相談します。

制約として、現時点で分かっていることを先にお伝えします。作成した本人以外はコードを直せません。私が異動した場合、後任は使えますが改修はできません。この点をどう扱うかについて、ご意見をいただけますでしょうか。

○○

---

付記

この資料の記述は、2026年8月5日時点の公式ドキュメントに基づいています。Claude Code のドキュメントは頻繁に更新されるため、審査に持ち込む前に第2章のURLを1つずつ開き、記述が変わっていないか確認してください。

ISO/IEC 42001 の取得状況は未確認です。https://trust.anthropic.com で確認してください。

社内で承認されている生成AIツールが別にある場合、第2章の7問の答えは、そのツールの公式ドキュメントで埋め替える必要があります。問いの構造と、第3章から第7章の内容はツールに依存しません。

---

効果の測り方

セッション S13 [20min] で使います。研修後、自部門で数字を作るときの手順書としても読めるようにしてあります。

---

1. 削減時間だけで測ると起きること

最初に、いちばん高くつく間違いから片づけます。

DORA が2026年3月10日に公開した「Balancing AI tensions」（Jessica Baolin、Nathen Harvey）に、次の一文があります。

the time saved during initial code or content generation is often re-allocated to verification overhead and prompting overhead

出典: dora.dev/insights/balancing-ai-tensions

最初の生成で浮いた時間は、検証の手間と、指示を書き直す手間に再配分される。同じ記事には現場の声も併記されています。コードを書く時間は減ったが、AIのお守りと、AIが何をやろうとしているかのレビューに時間を使っている。他人が書いたものをレビューするのは自分で書くより難しいのに、AIはレビューが必要な生成物の量だけを増やしている。

数字も同じ方向を指しています。AI利用90%、生産性が上がったと信じる層は80%超、それでも「ほとんど信頼しない」が30%。そしてAI導入度が高い組織ほど、スループットと不安定性（instability）が同時に上がります。

浮いた時間が売上に変わらない理由は3つに整理できます。

2026年6月2日の DORA 記事「Finding balance in the era of tokenmaxxing」（Evan Conaway）は、もっと露骨な例を挙げています。トークン消費量で社内ランキングを作っている企業が実在する。記事はこれを lines of code と同じ虚栄指標だと切り捨て、Goodhart の法則を明示的に引いています。指標が目標になった瞬間に、その指標は指標として死ぬ。不要な処理を回して消費量は水増しできますし、コストが10倍になってもスループットの伸びは限界的だった、と書かれています（dora.dev/insights/finding-balance-in-the-era-of-tokenmaxxing）。

代わりに DORA が推すのは、採用された変更1件あたりの費用（cost per accepted change）と、手戻り率（code rework rate）。そして個人ではなくチーム単位で見ること。

同じ罠は、指標を作った本人たちも警告しています。DX Core 4（2024年12月10日公開、Abi Noda ほか）は看板指標として Diffs Per Engineer を置きながら、目標や報酬に紐づけないこと、開発者体験の指標と対で見ること、運用を透明にすることの3条件を公式に明記しています（getdx.com/research/measuring-developer-productivity-with-the-dx-core-4）。指標を売っている側が「目標にするな」と書いている。この一点だけでも、社内で数値目標を配る前に一度立ち止まる価値があります。

---

2. 指標を3層に分ける

1つの数字で語ろうとすると必ず崩れます。動く速さが違うものを、層で分けます。

先行指標（月次）

作られた数だけを追うと、必ず「作った数を競う会」になります。共有された数と対で見てください。

中間指標（四半期）

効果測定ボードで積み上がるのがこの層です。対象業務あたりの所要時間を、導入前後で比較します。ここで測るのは1施策あたりの時間であって、部門全体の総労働時間ではありません。総労働時間は他の要因で動きすぎて、AIの寄与が読めません。

遅行指標（半期から通期）

役員が本当に見るべきはここです。ADL のようなプロフェッショナルファームでは、次の3つを推します。

同じ MIT SMR の記事は、フィラデルフィア・コミュニティカレッジで4年間、毎年2月1日から3月15日という同一の6週間を観察しています。見たのはタスク速度や自動化率ではなく、仕事の構成・意思決定の質・調整パターン。観察された変化は「調整はなくならず、会議から書くことへ、確認から最初から明確な原稿へ移った」でした。総量が減るのではなく、時間の置き場所が変わる。この形で報告できると、経営会議での議論が変わります。

もう1つ、Kirkpatrick Partners の Chief AI Officer である Myra Roldan の言葉を置いておきます。Adoption is not usage（導入は利用ではない）。導入率90%を報告した企業を調べたら、社員は議事メモの要約に使っていただけで戦略的価値はなかった、という例が挙がっています（kirkpatrickpartners.com、2026年6月22日）。同氏は、AIは初期にはマイナスまたは鈍い成果を示すことが多いので、弱い初期結果は撤退の判断材料ではなく診断データとして扱え、とも書いています。

---

3. 効果測定ボードの使い方

配布物 06_見本アプリ/01_効果測定ボード.html をダブルクリックしてください。入力した内容はブラウザの中に保存され、閉じても残ります。外部には何も送りません。

入力する項目

導入後の時間に何を含めるか

ここが、このボードを使う理由のほぼすべてです。

導入後の分数には、AIに指示を出した時間、出力を読んで確認した時間、直した時間、直しきれずに自分で書き直した時間を、全部足してください。第1節の DORA の指摘のとおり、浮いた時間の主な行き先がここです。ここを0分にすると、実態と合わない数字が出ます。

作成5分・確認と修正25分なら、導入後は30分です。導入前が40分なら削減は10分。この数字を持って経営会議に出るほうが、90%削減という数字を出して3か月後に否定されるより、はるかに安全です。

計算のしかた

ボードの中では次の式で動いています。

月あたり削減分 = （導入前 − 導入後）× 週あたり回数 × 使う人数 × 4.33
金額換算       = 月あたり削減分 ÷ 60 × 時間単価

4.33 は月あたりの週数です。状態が「停止」の行は0として扱われ、上部のKPIにも棒グラフにも反映されません。

時間単価は初期値を 12,000 円に置いてあります。ここは実勢のコンサルタント単価を入れないでください。単価を高く置くと分子が跳ねて、何を作ってもROIが立ちます。低めの値で固定し、施策どうしを比べられる状態を優先してください。比較のための共通の物差しであって、実際の金額ではありません。

出力

上部のKPIに、月あたりの削減時間、金額換算、動いている施策数、関わっている人数が出ます。「CSVで書き出す」を押すと表計算ソフトで開ける形式で保存できます。経営会議に出すときは、この CSV を貼るのではなく、第5節の1枚に落としてください。

---

4. 効果が出ていないと判定する基準

作った数を数える組織は必ず失敗します。見るべきは生存側です。

使われなくなったツールをどう見つけるか

ADL の環境では、各自の個人PCで動く単一HTMLが成果物です。利用ログを情報システム部門が自動で吸い上げる手段はありません。テレメトリが取れない以上、四半期ごとの棚卸し申告に寄せます。

設計のコツが1つあります。「使っているものを申告する」ではなく「使っていないものを申告したら褒める」形にしてください。前者だと誰も申告せず、台帳だけが太ります。後者だと廃止が進みます。

3か月ルール

作成から3か月使われなかったツールは捨てる。この運用を先に決めておいてください。

捨てるとは、ファイルを消すことではありません。台帳の状態を「停止」に変え、効果測定の集計から外し、保守の対象から外すことです。効果測定ボードで「停止」の行を消さずに残す設計にしてあるのは、何を試して何がやめになったかを記録として残すためです。

10個作って3個が生き残るなら、その3個の効果を10個分の工数で割ってください。生き残ったものだけを分子にも分母にも置く計算は、粉飾になります。

---

5. 経営会議に出す1枚

片面に収めます。載せるものと載せないものを先に決めます。

表の形

数字はすべて記入例です。実際の値を入れてお使いください。

運用の約束

守るべきことは3つです。個人ランキングを作らない。先行指標だけで成功を宣言しない。遅行指標が3四半期動かなければ、施策ではなく前提を疑う。

3つ目が実務ではいちばん難しく、いちばん効きます。利用率が上がって削減時間も積み上がっているのに意思決定の速さが変わらないなら、AIの使い方ではなく、決裁の設計に問題があります。

---

6. 他社の数字の読み方

公表されている数字は、分子と分母を確認してから使ってください。

LINEヤフーの発表（lycorp.co.jp/ja/news/release/018121）で効くのは「2倍」ではなく「3割」のほうです。全業務の3割を対象にした2倍なので、全体では最大でも1.18倍。分母を明示している点で誠実な発表です。逆に言えば、分母を書かない「生産性2倍」は読む価値がありません。

GMO（group.gmo/news/article/10079）の率の数字は強く、生成AI業務活用率98.7%、ほぼ毎日89.3%。ただし43.2万時間の算出根拠はリリースに書かれていません。自己申告アンケートの合算とみるのが妥当で、実測ではありません。

DORA の ROI レポート（dora.dev/ai/roi/report）は、数字より条件分岐が使えます。新規の単純な案件では35〜40%向上、複雑な既存資産の改修では約10%以下。変更失敗率が5%から6%へ1ポイント動くだけで、モデル上34.4万ドルの損失。レポート自身が「高い不確実性を含む見積もりであり、議論のきっかけであって厳密な数式ではない」と断っています。

読むときのチェックは4つです。

副作用の併記については、参考になる実測が2つあります。AI生成コードのセキュア率は約55%で2年間ほぼ動いていません（Veracode, 2026-03-24）。保守性の面では、重複ブロックが2023年比81%増、書き直しを示す移動コードが2022年の21%から2026年の3.8%へ低下（GitClear, 2026-01）。作った量の指標が伸びているとき、この2つが同時に悪化していないかを見る必要があります。

日本全体の位置も押さえておいてください。IPA「DX動向2026」では、DX成果指標を設定している企業は23.9%。設定していない理由の最多は「評価指標の設定方法がわからない」で36.0%、2024年度の28.7%から約7ポイント悪化しています。測り方を決められない側が多数派です。今日ここで自部門の指標を1つ決めれば、それだけで上位25%に入ります。

ちなみに効果測定ボードの初期データには「問い合わせの一次分類」という停止済みの行が入っています。導入前15分・導入後15分、つまり効果ゼロで止めた施策です。消さずに残してあります。

---

社内に広げる道筋

セッション S14 [20min] で使います。研修後、自部門の展開計画を書くときの下敷きとしても使えます。

---

1. 広がらない理由

日本企業の現在地を1行で言うと、個人利用だけが増えています。

IPA「DX動向2026」（2026年7月16日発表、有効回答1,799社、調査期間2026年4月中旬から6月中旬、実査はNTTデータ経営研究所）の数字です。

出典: IPA DX動向2026

63.3% と 11.9% の差、この51ポイントが今日の主題です。IPA はこの分布について「2024年度の傾向と大きな変化はない」と明記しています。1年経って、個人利用だけが増えました。

差の正体は同じ報告書の中にあります。使い方を知らないからではありません。組み込む先の業務プロセスと、データと、責任者が定義されていないからです。

結果も同じ形で出ています。効果として「業務が効率化・迅速化した」は91.6%。一方で「顧客満足度が向上した」4.5%、「売上や利益が向上した」3.9%。用途も「文書・音声の要約・翻訳・校正」82.5%、「文書・レポートの作成」80.5%に対し、「自社製品・サービスの高度化」10.9%、「生産・物流・サービス提供の計画支援」6.0%。

国際比較も置いておきます。総務省「令和8年版 情報通信白書」（2026年7月24日公表）の企業調査で、生成AIによる業務変革について「組織的な取組はない」は日本27.0%、米国1.4%、ドイツ4.9%、中国2.6%。「特に実施している施策はない・把握していない」は日本19.9%、米国0.7%。白書本文は、業務プロセス見直しのスキルを学ぶ環境（日本39.9%、米国62.7%）と社内データの参照環境（日本24.5%、米国57.2%）の2項目を、他の3か国より顕著に低いと名指ししています。

ADL 自身が2026年6月17日の報告書「AI-First or Disrupted: Beating the Nightmare Competitor」で、勝敗を決めるのは導入の速さではなく組織変革の有無だと述べています。パートナー Petter Kilefors の言葉として、本当の分断は導入企業と非導入企業の間ではなく、仕事を最適化する側と仕事を消す側の間にある、と書かれています（Businesswire, 2026-06-17）。63.3% から 11.9% へ渡る作業は、まさにその組織変革の側にあります。

---

2. 30日・90日・180日

3つの期間で、誰が何をして、何が満たされたら次へ進むかを決めます。

30/60/90 の公式テンプレートで日本語の一次出典が確認できるものは、今回の調査では見つかりませんでした。上の表は IPA と情報通信白書のデータから逆算した設計案です。根拠は各行に紐づけてあります。最初の30日を「測る対象を決める」に充てるのは、成果指標を設定している企業が23.9%しかなく、設定しない理由の最多が「評価指標の設定方法がわからない」36.0%（2024年度28.7%から約7ポイント悪化）だからです。

役員本人が最初の30日にすること

号令をかけることではありません。次の5つです。

4番目について補足します。ADL の環境では ChatGPT 以外のAI利用が不可で、各自が個人PCを使い社内ネットワークには接続しません。この制約下では、役員が自分で触ることの意味が2つ増えます。制約の中で何が作れて何が作れないかを、報告ではなく手触りで判断できること。そして、情報システム部門への説明を自分の言葉でできることです。

---

3. 誰から始めるか

3つの型があります。

CoE方式の一次情報としては、Microsoft の Cloud Adoption Framework「Establish an AI Center of Excellence」（最終更新2026年6月26日、learn.microsoft.com）が具体的です。経営スポンサーを先に確保し、月次レビューと経営層への直通ルートを作らないと、CoE は標準を強制できないと明記されています。初期は集中型で立ち上げ、成熟に伴ってアドバイザリー型へ移す。移行の判断材料として、承認の遅延、CoEの専門家が全チームを支えきれない知識のボトルネック、CoEと事業チームが価値提供ではなく優先順位を議論している状態、の3つが挙がっています。

チャンピオン方式が効いた例は Bain です。社内ツール Sage を起点に、社内で19,000超のカスタムGPTが作られています（Bain公式ブログ, 2025-08-21）。ただし19,000個の大半は作った本人しか使っていないとみるのが自然で、これは第5節の横展開問題そのものです。数を誇る指標には身内から批判も出ています。PwC のチーフAIオフィサー Dan Priest は「それはたぶん間違った指標だ」、EY の Steve Newman は「最も価値を返しているのはごく少数のエージェントだ」と述べています。

段階展開方式の国内事例は中外製薬です。経営層が「競争環境の中でいつディスラプトされるかわからない」という危機意識を明示したうえで、汎用的な生成AI利用から業務変革までを「AI Everyday」「AI Everywhere」「AI Transformation」の3段に置いています。事業部門のニーズを起点にDX推進部門が技術を橋渡しし、全社員参加のアイデア創出プログラムを回しています（出所は情報通信白書のヒアリング要約）。規模の小さい例では、アイニコグループが経営者主導の集中プロジェクトで1年間の定期進捗確認を回し、全10事業部合計で年間2,247時間の業務時間削減という結果を出しています。

コンサルティングファームへの推奨

段階展開方式を主軸に置き、チャンピオン方式を各段の中で使ってください。CoE は作らないほうがよいと考えます。

理由を述べます。ADL のような専門職ファームで CoE を作ると、ほぼ確実に審査機関になります。審査機関になった瞬間、パートナーは使わなくなります。承認を待つより自分で ChatGPT を開いたほうが速いからです。CoE が機能する条件は Microsoft の文書に書かれているとおり、経営スポンサーと直通ルートと標準の強制力ですが、その強制力がパートナーの裁量と正面衝突します。

代わりに、段に名前をつけてください。「全社導入」という単一目標だと、63.3%の個人利用に到達した時点で「もう入れた」と誤認されます。中外製薬の3段は、いまどこで詰まっているかを会議で言語化するための道具として機能しています。

チャンピオン方式を段の中で使うというのは、各部門で最初に手を挙げた人を「その段の担当」として指名し、次の段へ進む条件を判定させる形です。MIT NANDA の調査（2025年8月、経営層150名へのインタビュー、社員350名への調査、公開導入事例300件の分析。Fortune, 2025-08-18 経由）は、成功要因の1つとして、中央のAIラボではなくライン管理者に導入を主導させた組織が成功していることを挙げています。同じ調査で、企業の生成AIパイロットの約95%が測定可能な損益への影響をほぼ生んでいない、とも報告されています。

---

4. パイロットから本番への判定基準

Microsoft の CoE 文書は、業務価値・技術的な実現可能性・必要資源の一貫した基準を挙げるにとどまり、閾値は示していません。実務で使える形にすると、次の6条件を全部満たすかどうかで見ます。

4番と5番が欠けたまま横展開した結果が、Bain の19,000カスタムGPTのロングテールであり、日本企業の11.9%です。この2つは他の4つより優先度が高いと考えてください。

---

5. 横展開の障壁

保守・権限・データ・責任の4つが、実際の事故として現れています。

4つのうち、ADL の環境で最も現実的に効くのはデータです。保守と権限は、成果物を単一HTMLに固定してある限り、規模がそもそも小さい。責任は第4節の条件4で押さえます。データだけは、横展開の瞬間に必ず表面化します。

---

6. やめどきの決め方

撤退の判断を、始める前に決めておいてください。

理由は単純です。始めた後だと、決めた人の面子が判断に混じります。誰かの推した施策を止める会議は、始める会議の10倍難しい。始める時点で条件を紙に書いておけば、止める判断は事務作業になります。

止めるのは施策であって、人ではありません。ここを混同すると、次から誰も手を挙げなくなります。効果測定ボードで停止した行を消さずに残す設計にしてあるのは、そのためでもあります。何を試して何がやめになったかが記録として残っていれば、止めることは失敗ではなく前進の記録になります。

ただし例外を1つ置きます。Kirkpatrick Partners の Myra Roldan は、AIは初期にはマイナスまたは鈍い成果を示すことが多いので、弱い初期結果は撤退の判断材料ではなく診断データとして扱え、と述べています（kirkpatrickpartners.com、2026年6月22日）。最初の90日の数字が弱いこと自体は、止める理由になりません。止める理由になるのは、弱い理由を誰も説明できないことです。

---

7. 経営層が手を動かすことの効果

正直に書きます。「経営層が自らコードを書くと社内普及が速い」という直接の統計は、今回の調査では確認できていません。この主張を裏づける一次データは、現時点で手元にありません。

代わりに、方向が近い材料を3つ挙げます。

いずれも相関であって、因果ではありません。見識のある経営者がいる会社で成果が出ているのか、成果が出ているから経営者が見識を持つに至ったのかは、このデータからは判別できません。

それでも役員が自分で1本作ることを推す理由は、データではなく実務上の理由です。作ってみないと、何が作れて何が作れないかの線が引けません。線が引けないと、部下から上がってきた提案を判定できません。判定できないと、結局その提案は宙に浮きます。

Wachtell, Lipton の Kevin Schwartz は逆の立場を取っています。取締役会の役割は中核的な技術ツール・影響を受ける重要ワークフロー・経営陣の報告プロセスへの可視性を保つことであり、個々のツールを承認する必要も、取締役個人が専門性を身につける必要もない、と明言しています（Roles and Responsibilities: Threshold Questions in Enterprise AI Adoption、2026年5月25日）。

この論点は決着していません。取締役会としての監督責任と、事業執行者としての判断能力は別の話だ、というのが本研修の立場です。今日の6時間は後者のために使っています。

---

8. 持ち帰るもの

今日の終わりに、次の1枚を書いてください。

最後の行が、いちばん効きます。役員だけを鍛えても、ライン管理者に権限が渡らなければ現場の行動は変わりません。委ねる範囲を1行で書けるかどうかが、63.3% の側に留まるか 11.9% の側へ渡るかの分かれ目になります。

---

AI内製ルールのひな型

ルールを置く理由は、作らせないためではありません。作ってよい範囲を先に決めておかないと、判断できる人が一人ずつその場で判断することになり、迷った人から順に手を止めます。禁止事項だけを並べた規程は、現場では「触らないでおく」という結論に翻訳されます。だからこのひな型は、作ってよいものを先に書き、作ってはならないものを後に書く順序にしてあります。禁止の列挙は最小限にとどめ、届出と台帳という記録の側で担保します。

このひな型の使い方

〔　〕は自社の部門名・役職名・日数に置き換えてください。条文はそのまま社内規程の下敷きとして使える硬さで書いてあります。各条の下にある「守っているもの」は社内説明用の注記で、規程本体には入れません。全14条ありますが、初日から全部を課す想定ではありません。最後の「適用の段階」を先に読んでから戻ってきてください。

表計算マクロ、Access、RPAで三度起きたことをここでも繰り返さないための設計にしています。三度とも失敗の形は同じでした。台帳がない、責任者がいない、検証されない、作った人が異動する。過去の経験で分かっているのは、禁止した会社より登録させた会社のほうが結果的に事故が少ないという一点です。禁止しても作ることは止まらず、台帳から消えるだけでした。

---

生成AIを用いた業務ツール内製に関する規程（ひな型）

第1章 総則

第1条（目的）

この規程は、〔当社〕の役職員が生成AIを用いて業務ツールを作成し、利用し、または配布する場合の範囲、手続および責任を定め、業務効率の向上と情報の保護を両立させることを目的とする。

守っているもの: 現場が「作ってよいか分からないから作らない」で止まる状態を防ぎます。目的条に効率向上を先に書くのは、この規程が推進側の文書であることを最初に示すためです。

第2条（適用範囲）

1. この規程は、〔当社〕のすべての役職員（派遣社員および業務委託先の従事者を含む。以下「役職員」という）に適用する。
2. この規程は、業務のために作成される内製ツールに適用する。私的な用途にのみ用いるものには適用しない。
3. 情報セキュリティ規程、個人情報保護規程および秘密保持に関する契約上の義務は、この規程に優先する。

守っているもの: 適用対象を人ではなく用途で切ることで、「これは業務か私用か」の判断だけで済むようにしています。既存規程との優先順位を先に書いておかないと、条文どうしがぶつかったときに現場が止まります。

第3条（定義）

この規程において、次の各号に掲げる用語の意義は、当該各号に定めるところによる。

1. 内製ツール　生成AIの支援を受けて役職員が作成した、業務に用いるソフトウェアまたはファイルをいう。単一のHTMLファイル、表計算ファイルに組み込んだ処理、スクリプトその他の形式を問わない。
2. 業務利用　作成者本人以外が使用し、業務上の意思決定に用い、または成果物として社外に提出する行為をいう。作成者本人が試行のために動かす行為は含まない。
3. 公開情報　〔当社〕または第三者がすでに公表している情報であって、公表の事実および出所を確認できるものをいう。公表されているか否かが不明な情報は、公開情報として扱わない。
4. 業務オーナー　当該内製ツールが支える業務について責任を負う役職者をいう。作成者と同一である必要はない。
5. 試行　作成者本人のみが使用し、他者に配布せず、業務上の意思決定に用いない状態をいう。

守っているもの: 「業務利用」の線を、作成者本人以外が触れるかどうかで引いています。ここを曖昧にすると、試作品が誰にも気づかれないまま本番運用へ昇格します。RPAで最も多かった事故がこの形でした。

第2章 作成の範囲

第4条（作成してよいもの、作成してはならないもの）

1. 役職員は、次に掲げる内製ツールを、第3章に定める手続に従って作成することができる。
   1. 自己または自部門の反復作業を代替するもの
   2. 公開情報またはダミーデータのみを扱う集計、可視化、書式変換を行うもの
   3. 社内の検討資料または提案の下書きを作成するもの
   4. 端末内で完結し、外部に情報を送信しないもの
2. 役職員は、次に掲げる内製ツールを作成してはならない。
   1. 会計帳簿、決算数値または財務報告に用いる数値を生成し、加工し、または確定させるもの
   2. 人事評価、採用の合否、与信その他個人の権利利益に影響する判断を行い、または当該判断を支援するもの
   3. 基幹システムに書き込み、または基幹システムの認証情報を保持するもの
   4. 顧客に提供する成果物そのもの、または顧客の業務環境で動作させることを予定するもの
   5. 個人情報を保存し、または外部に送信するもの
3. 前項に該当するものを作成する必要が生じた場合は、第14条の手続による。

守っているもの: 決算数値に触れた瞬間、そのツールは内部統制の評価対象になります。触れないうちは自由に作ってよい。この境界を最初に引いておけば、監査対応の話と内製推進の話は衝突しません。第2項第2号は、EU AI Actが高リスクとして列挙している領域と重なる部分です。

第5条（入力してはならない情報）

1. 役職員は、生成AIに対し、次に掲げる情報を入力してはならない。
   1. 顧客の名称その他顧客を特定できる情報
   2. 秘密保持契約の対象となる情報
   3. 公表前の財務情報、投資情報および人事情報
   4. 個人情報および要配慮個人情報
   5. 営業秘密として管理している情報
   6. 認証情報、アクセスキーその他の秘密情報
2. 前項各号に該当する情報を扱う必要がある場合は、業種、規模および分析の軸のみを残し、固有名詞および実数値を除いた形に置き換えたうえで入力する。
3. 生成AIを起動する作業フォルダには、当該業務に必要なファイルのみを置く。複数の案件のファイルを含むフォルダで起動してはならない。

守っているもの: 抽象的に「機密情報を入れない」と書いても運用されません。判断が要らない列挙に落としています。第3項は見落とされやすい点で、生成AIのコーディングツールは起動したフォルダとその配下を読み取ります。デスクトップ直下や案件フォルダのルートで起動すると、隣の顧客の資料まで読み取りの射程に入ります。ファイル名による除外設定は読み取り制限として機能しません。

第6条（使用してよいツールおよび契約）

1. 役職員は、〔情報システム部門〕が承認し、〔当社〕が法人として契約したツールのみを業務利用に用いる。承認済みツールの一覧は〔情報システム部門〕が維持し、社内〔ポータル〕に掲示する。
2. 役職員は、個人名義で契約したアカウント、無償のアカウントおよび個人の支払手段で契約したアカウントを、業務利用に用いてはならない。
3. 役職員は、法人契約のアカウントに〔当社〕が指定する認証方法でログインし、他の組織の認証情報でログインしてはならない。
4. 第2項の禁止にかかわらず、研修その他の目的で個人端末および個人アカウントを用いる必要がある場合は、対象者、期間、扱ってよいデータの区分および終了後の消去手順を定めた文書について、あらかじめ〔情報システム部門長〕の承認を得る。

守っているもの: 個人アカウントを禁じる根拠は3つあります。第一に、主要な生成AIサービスの個人向けプラン（無償、Pro、Maxなど）は、利用者が設定を有効にしていると入力内容がモデルの学習に使われ、保持期間が30日から最長5年に延びます。法人向け（Team、Enterprise、API、クラウド基盤経由）は学習に使われず、保持は標準30日です。第二に、個人アカウントには会社の管理設定が届きません。禁止操作を組織側で強制する仕組みも、利用ログを組織の収集基盤へ送る設定も、端末とアカウントを管理下に置いて初めて効きます。第三に、監査ログが会社に残りません。事故が起きたときに何が入力されたかを追えないという意味です。

第4項は逃げ道ではなく、シャドーITと承認済み例外を分けるための条文です。私物端末での利用が黙認や自己判断で始まっていればシャドーIT、対象と期限とデータ区分を文書で確定して経営が承認していれば、統制が効かないと分かったうえで意図的に受け入れた状態になります。技術的な差はありません。差は承認記録と期限の有無だけです。

第3章 手続

第7条（作成前の届出および作成後の登録）

1. 役職員は、内製ツールを業務利用しようとするときは、あらかじめ〔別紙2〕の届出書により〔所属部門長〕に届け出て、承認を得る。試行にとどまる間は、届出を要しない。
2. 前項の届出において、扱う情報に第5条第1項各号に該当するおそれがあるときは、〔情報システム部門〕の確認をあわせて得る。
3. 承認を得た内製ツールについて、作成者は〔別紙1〕の台帳に登録する。登録は業務利用を開始する前に行う。
4. 台帳は〔情報システム部門〕が管理し、〔所属部門長〕および〔内部監査部門〕が随時閲覧できる状態に置く。
5. 内製ツールの目的、扱うデータまたは利用者の範囲を変更したときは、作成者は台帳の記載を更新する。

守っているもの: 統制点は台帳ひとつだけです。外部の法令は社内の業務効率化ツールを見ていません。日本のAI推進法（令和7年法律第53号）は活用事業者に努力義務を課すのみで罰則がなく、EU AI Actのデータベース登録義務は高リスクAIが対象で、社内の効率化ツールはまず該当しません。だから台帳が唯一の証跡になります。生成の速度は過去と桁が違い、表計算マクロが数日かかったところを数十分で作れます。台帳が追いつかない前提で、届出の対象を業務利用に限っています。

第8条（自己点検および第三者確認）

1. 作成者は、業務利用を開始する前に、次の各号について自ら点検し、結果を記録する。
   1. 情報が外部に送信されるか。送信される場合はその宛先
   2. 情報がどこに保存されるか
   3. 誰が閲覧できるか
   4. 利用を終了するときにどう消すか
2. 前項の点検の結果は、〔別紙3〕の点検レポートとして保存し、台帳の点検日欄に実施日を記載する。
3. 次のいずれかに該当する内製ツールについては、作成者以外の者による確認を受けなければならない。
   1. 3名以上が利用するもの
   2. 社外の者が閲覧する情報を出力するもの
   3. 継続的に同じ処理を自動で繰り返すもの
4. 前項の確認者は、〔所属部門長〕が指名する。確認者は作成者と同一であってはならない。

守っているもの: 自分が書いたものを自分だけで点検した状態を、確認済みとは呼びません。第3項第3号を入れているのは、止まらない仕組みが最も危ないからです。RPAの野良ロボットで実際に起きたのは、業務の手順が変わったのにロジックが更新されず、誤った処理を毎日正確に繰り返すという事故でした。誰も気づきません。

分量の根拠として、Veracodeが100を超えるモデルを対象に行った検証（2025年7月30日公表）では、安全な書き方と危険な書き方を選べる場面で45%が危険なほうを選びました。この数字はAIで作るなという根拠ではなく、確認を挟まずに人へ渡すなという根拠です。裏を返せば、確認を1回入れれば使えます。

第9条（配布および公開の範囲）

1. 内製ツールの配布は、原則として〔当社〕が管理する手段により行う。個人の記録媒体および個人の記録領域を用いてはならない。
2. 内製ツールをインターネット上で公開する場合は、あらかじめ〔情報システム部門長〕の承認を得る。認証を設けない公開は、公開情報のみを扱うものに限る。
3. 顧客に提出する成果物に、生成AIにより作成しまたは改変した文章、図表または画像を含める場合は、〔当社〕が定める表示の方法に従う。
4. 内製ツールを社外に提供してはならない。顧客の業務で用いる必要が生じた場合は、第14条の手続による。

守っているもの: 第3項はEU AI Act第50条の透明性義務に対応します。この条項は先送りされていません。高リスクAIの規制は2027年12月2日および2028年8月2日へ延期されましたが、透明性義務は2026年8月2日から現に執行が始まっています。対話型AIは相手にAIであることを告げる、AIが生成または改変したコンテンツには機械可読な表示を付ける、という内容です。EU拠点の顧客に納品する成果物にAI生成の図表や文章が含まれる場合、今この瞬間が対象です。

第10条（保守の責任者および異動時の取扱い）

1. 内製ツールごとに業務オーナーを1名定め、台帳に記載する。業務オーナーは個人名ではなく〔役職名〕で記載する。
2. 業務オーナーは、当該内製ツールの継続、改修または廃止を判断する責任を負う。
3. 作成者が異動または退職するときは、当該作成者は業務オーナーに対し、当該内製ツールの一覧、動作の前提および既知の制約を引き継ぐ。引き継ぎが完了しない内製ツールは、業務オーナーの判断により停止する。
4. 業務オーナーが不在となった内製ツールは、〔情報システム部門〕がこれを停止し、台帳の状態欄に停止と記載する。

守っているもの: 個人名で持たせると、異動のたびに責任者が消えます。業務のほうは残るので、役職で持たせます。第3項の後段は厳しく見えますが、引き継がれなかったものが動き続ける状態のほうが危険です。過去3回の教訓で最も繰り返されたのがこの形でした。

第11条（棚卸しおよび廃棄）

1. 〔情報システム部門〕は、〔四半期〕ごとに台帳の棚卸しを行い、各内製ツールについて業務オーナーに継続、改修または廃止のいずれかを確認する。判断は業務オーナーが行い、〔情報システム部門〕は判断を求める役割を担う。
2. 内製ツールの利用許可には有効期限を定める。期限は登録の日から〔6か月〕とし、延長は前項の棚卸しにおける継続の判断をもって行う。
3. 〔3か月〕以上利用の記録がない内製ツールは、業務オーナーの確認を経て停止する。
4. 廃止する内製ツールについては、次の各号をすべて実施し、実施日を台帳に記載する。
   1. ファイルの削除
   2. 参照している他の資料からの切り離し
   3. 閲覧権限の解除
   4. 後継となる手段の明示、または当該業務を行わないことの確認

守っているもの: 期限つきの利用許可が、過去のEUC統制で最も欠けていた要素です。期限がないと、棚卸しは「まだ使っています」を集める作業になります。第1項で判断者を業務オーナーに固定しているのは、情報システム部門が判断側に回ると、部門の実情を知らないまま全部を継続と処理してしまうためです。

第12条（事故が生じた場合の報告）

1. 役職員は、次の各号のいずれかを認識したときは、直ちに〔所属部門長〕および〔情報システム部門〕に報告する。報告は事実の把握を待たずに行う。
   1. 第5条第1項に定める情報を入力したこと、またはその疑いがあること
   2. 内製ツールから情報が外部に送信されたこと、またはその疑いがあること
   3. 内製ツールの出力の誤りにより、社外に誤った情報を提供したこと
   4. 内製ツールが意図しない相手に閲覧されたこと
2. 前項の報告を受けた〔情報システム部門〕は、当該内製ツールの利用を暫定的に停止させることができる。
3. 個人情報の漏えいまたはそのおそれがある場合は、個人情報保護規程に定める手続による。
4. 報告した役職員は、報告したことのみを理由として不利益な取扱いを受けない。

守っているもの: 第4項がこの条文の中心です。報告した人が責められる運用になると、事故は報告されずに隠れます。第1項の後段も同じ理由で、原因が分かってから報告する運用にすると初動が数日遅れます。個人情報保護法は2026年7月10日成立の改正で課徴金制度が導入されました。施行は公布日である2026年7月17日から2年を超えない範囲です。日本企業のAI利用で実際に金額が動くのは、AI推進法ではなく個人情報保護法のほうです。

第13条（記録および経営への報告）

1. 〔情報システム部門〕は、〔半期〕ごとに、台帳の登録件数、棚卸しの結果、事故の件数および対応状況を〔経営会議〕に報告する。
2. 前項の報告は、議事録に記録する。

守っているもの: 会社法第362条第4項第6号と会社法施行規則第100条が求める内部統制システムの構築義務のもとで、AIのリスクもこの枠に入ります。判例上、問われるのは結果ではなく体制です。取締役会でAI利用のリスクと統制が審議され、議事録に残っているかどうか。事故が起きたときに「想定していなかった」ではなく「想定して手当てしていた」と言えるかどうかで、責任の所在が変わります。この条文は、その記録を作るためだけに置いています。

第14条（例外の承認）

1. この規程に定める範囲を超えて内製ツールを作成し、または利用しようとする場合は、次の各号を記載した書面により〔情報システム部門長〕および〔担当役員〕の承認を得る。
   1. 例外を必要とする理由および代替手段を採らない理由
   2. 対象となる業務、データおよび利用者の範囲
   3. 有効期間。〔6か月〕を上限とする
   4. 期間中に講じる措置および終了時の処理
2. 承認した例外は台帳に登録し、状態欄に例外と記載する。
3. 承認は有効期間の満了により失効する。継続を要する場合は、あらためて第1項の手続による。

守っているもの: 例外を認めない規程は、例外が水面下で運用されるだけです。期間の上限と自動失効を入れておくと、例外が恒久化しません。承認者を2名にしているのは、情報システム部門だけでは事業上の必要性を判断できず、事業側だけでは技術的な影響範囲を判断できないためです。

附則

1. この規程は〔　年　月　日〕から施行する。
2. この規程は、〔年1回〕見直す。関係法令の改正があった場合は、その都度見直す。

---

別紙1 内製ツール台帳

各列の書き方。

10列すべてを最初から必須にすると、誰も書かなくなります。試行段階では管理番号、名称、作成者、目的、状態の5列だけを必須にし、残りは第2段階から埋めさせてください。項目が多い台帳は、埋まっていない台帳になります。埋まっていない台帳は無いのと同じです。

業務オーナーの欄をこの表に置いていないのは、第10条で役職名により定めるためです。運用上は、利用者の列に業務オーナーの役職名を併記する形でも構いません。

---

別紙2 内製ツール作成届（記入例つき）

内製ツール作成届

提出日        2026年9月1日
提出者        〔部門〕〔氏名〕
承認者        〔所属部門長〕

1. 作るもの
   名称          案件別工数集計ボード
   形式          単一のHTMLファイル1本
   代替する作業   各自が表計算ファイルで作っている月次の工数集計

2. 使う道具
   ツール名      〔承認済みツール名〕
   契約          法人契約（〔契約名義〕）
   注記          個人契約のアカウントは使用しない

3. 扱うデータ
   区分          社内情報（個人情報を含まない）
   入力するもの   案件コード、作業時間、担当部門
   入力しないもの 顧客名、契約金額、個人の氏名

4. 使う人
   範囲          〔部門〕内 5名
   業務オーナー   〔部門〕〔役職名〕

5. 情報の行き先
   外部への送信   なし
   保存場所      利用者のブラウザ内（端末外に出ない）
   閲覧できる人   当該端末の利用者のみ

6. やめるとき
   停止方法      ファイルを削除する。参照している共有資料のリンクを外す
   後継手段      従来の表計算ファイルに戻す

7. 有効期限
   2027年3月1日まで（棚卸しで延長の可否を判断）

承認欄
   所属部門長        日付        署名
   情報システム部門   日付        署名
   （3の区分が「個人情報を含む」または顧客情報を含む場合のみ）

この届は1枚に収めます。項目を増やした瞬間、提出されなくなります。7項目のうち5と6が最も重要で、この2つに答えられないものは、まだ作る段階にありません。

---

適用の段階

全14条を初日から課すと、届出が出てこなくなり、内製が水面下に潜ります。3段階で入れてください。

第1段階 試行期（開始から〔90日〕）

適用する条文は第1条から第6条まで、第10条、第12条。

この期間に守らせるのは、ツールの契約と入力してよい情報だけです。届出も台帳も求めません。作った本人だけが使う限り、統制の必要はありません。ここを縛ると普及が止まります。

期間中に集めるのは、何本作られたか、どの業務が対象だったか、誰が作ったかの3点。台帳ではなく、〔情報システム部門〕が作成者に聞き取る形で構いません。

第2段階 拡大期（〔90日〕以降）

第7条、第8条第1項および第2項、第9条、第11条を追加します。全条文のうち第8条第3項と第13条を除く範囲です。

届出と台帳登録がここから始まります。第1段階で作られたものは、業務利用を続けるものだけを遡って登録させてください。全部を登録させると、登録作業だけで数週間が消えます。

第8条第3項の第三者確認は、この段階では推奨にとどめます。確認を担える人の数が足りないためです。

第3段階 定着期（第2段階の開始から〔6か月〕以降）

全14条を適用します。第8条第3項の第三者確認と、第13条の経営会議への報告がここで加わります。

この段階に進む条件は日数ではありません。台帳の登録件数が実態と合っていること、棚卸しが1回完了していること、確認を担える人が〔部門〕ごとに1名以上いること。この3つが揃うまでは第2段階にとどめてください。

段階を進める判断

各段階で見るのは次の3つです。

報告が0件で推移している状態は、事故がないのではなく、報告されていないことを疑います。全件が継続と判断される棚卸しは、棚卸しをしていないのと同じです。

---

参照した規範

各条文の下敷きにした資料です。いずれも2026年8月5日時点で確認したものです。社内規程として確定させる前に、施行日と版が更新されていないかを確認してください。

AI事業者ガイドライン 第1.2版

総務省・経済産業省が2026年3月31日に公表しました。改訂の履歴は、第1.0版が2024年4月19日、第1.01版が2024年11月22日、第1.1版が2025年3月28日、第1.2版が2026年3月31日です。第1.2版でAIエージェントとフィジカルAIが正式に対象として明記され、用語の定義も整理されました。文脈内学習は「学習」に含めず、RAGによるデータ参照は「推論」に含めるという整理です。

本編と別紙のほか、別紙7としてチェックリストとネットワークシート（Excel形式）が同梱されています。全主体向けチェックリストの項目は、人権侵害の回避、安全性の確保、バイアスの評価、プライバシー保護と関係法令の遵守、不正操作を防ぐセキュリティの確保、透明性の確保、トレーサビリティとアカウンタビリティ、AIガバナンスおよびプライバシーポリシーの策定、自社の状況に応じた具体的アプローチの検討の9項目です。この規程の第5条、第8条、第9条はこのチェックリストに対応させています。

掲載ページ: https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html

無償の日本語ひな型としては日本ディープラーニング協会の「生成AIの利用ガイドライン」がありますが、最新が第1.1版で2023年10月のまま更新されていません。EU AI Act第50条にも2026年改正個人情報保護法にも対応していないので、そのまま使うことはできません。骨格だけ借りて中身を差し替える扱いになります。

EU AI Act の施行状況

改正法はRegulation (EU) 2026/1744、通称Digital Omnibus on AIです。2026年7月8日採択、7月24日に官報掲載、2026年7月27日発効。

2026年8月2日から現に適用が始まったのは第50条の透明性義務です。対話型AIは相手にAIであることを告知する、ディープフェイクは表示する、AIが生成または改変したコンテンツには機械可読なマークを付ける。欧州委員会のAI Officeと加盟国当局が監督と執行を開始しています。すでに市場に出ている生成AIには4か月の移行期間があります。

先送りされたのは高リスクAIの規制です。附属書III（生体認証、重要インフラ、教育、雇用、移民・国境管理など）が2027年12月2日、附属書I（製品組込み型）が2028年8月2日。当初はいずれも2026年8月2日でした。第6条では安全コンポーネントの定義が絞られ、利用者支援、性能最適化、効率化、自動化、利便性のみを目的とするAIは除外されました。社内の業務効率化ツールは、この除外に該当する可能性が高い部類です。

第4条のAIリテラシー義務も改正されました。従業員に一定水準のリテラシーを確保させる義務から、リテラシーの育成を支援する措置をとる義務へ軟化し、主たる責任は欧州委員会と加盟国に移りました。社内教育をEU法の義務として説明する根拠は弱まっています。裏を返せば、社内教育は法令遵守ではなく経営判断としてやる話になりました。

欧州委員会発表: https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august

改正個人情報保護法

2026年7月10日に第221回国会で成立、7月17日公布。施行は公布から2年を超えない範囲で政令が定める日です。具体的な施行日は政令待ちで、委員会規則とガイドライン整備のロードマップが2026年7月31日の第364回委員会で決定されています。

この規程に関係するのは2点です。

課徴金制度の導入（第148条の3から第148条の17）。重大な違反により権利利益が侵害された場合、違反行為で得た財産的利益等に相当する額の納付を命じられます。命令の要件も見直され、罰則も引き上げられました（第178条から第180条）。

統計作成等にのみ利用される場合について、個人データの第三者提供と、公開された要配慮個人情報の取得に本人同意を不要とする規定（第30条の2、第31条の3）。委員会の概要資料には「統計作成等であると整理できるAI開発等を含む」と明記されています。ただし特定個人の評価や判定、個人を識別できる分析結果の作成や公表、マーケティングや採用判断への転用は認められません。この規程の第4条第2項第2号は、この線に合わせています。

個人情報保護委員会: https://www.ppc.go.jp/personalinfo/legal/r8kaiseihogohou/

なお、日本のAI推進法（人工知能関連技術の研究開発及び活用の推進に関する法律、令和7年法律第53号、2025年6月4日公布）に罰則はありません。第7条の活用事業者の責務は努力義務です。日本企業のAIガバナンスで実際に金額が動くのは、個人情報保護法のほうだと理解しておいてください。

ISO/IEC 42001

ISO/IEC 42001:2023はAIマネジメントシステムの認証規格で、2023年12月発行です。Annex Aに9グループ38の管理策があり、AI方針、内部組織、資源、影響評価、システムライフサイクル、データ、利害関係者への情報提供、AIシステムの利用、第三者関係で構成されています。影響評価の方法論はISO/IEC 42005:2025に分離されました。

この規程で対応するのは、システムライフサイクルと影響評価の2つです。第7条の台帳、第8条の点検記録、第11条の棚卸しと廃棄の記録は、将来認証を取得する場合にそのまま証跡になります。逆に言えば、認証を取らない場合でも、この3つの記録があれば説明はできます。

日本の認定スキームはISMS-ACが運営するAIMSです。認定開始は2025年7月8日、最初の認定認証機関の誕生が2026年1月14日。認証取得組織の公表数は10で、2026年8月5日時点の値です。認証機関はテュフ ラインランド ジャパンとSGSジャパンの2社。日本ではまだほとんど普及していない段階です。

海外は先行しています。BCGが2026年1月27日に「世界最初の100組織」の一角として取得を発表しました。国内ではABEJAが2026年7月29日、ITbookが2026年4月14日、パーソルクロステクノロジーが2026年7月16日に取得しています。取得の工数と費用について、認証機関が公表する一次データはこの調査では見つかりませんでした。

ISMS-AC: https://isms.jp/aims/index.html

既存の内部統制の枠組み

新しい統制を作る必要はありません。財務報告に係る内部統制の評価及び監査の基準並びに実施基準は2023年4月7日に改訂され、2024年4月1日以後に開始する事業年度から適用されています。この基準の本文にEUCや表計算という語は出てきませんが、ITに係る全般統制（システムの開発・保守、運用・管理、アクセス管理、外部委託契約の管理）と、ITに係る業務処理統制（入力情報の完全性・正確性・正当性、例外処理の修正と再処理、マスタデータの維持管理、利用の認証と操作範囲の限定）という枠組みが、そのまま内製ツールに移植できます。

金融庁: https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html

ちなみに、この規程を作るときに一番時間を使うべきなのは条文ではなく、第5条第1項の列挙です。他の条文は他社のひな型から借りられますが、何を入力してはいけないかだけは、自社の顧客契約と業務の実態からしか決められません。ここが具体名で埋まっていない規程は、読まれても運用されません。