Rui Software生成AI活用を「現場任せ」にしない：情シスに求める「守る・つなぐ・測る・育てる・止める」5つの業務
生成AIを「使ってよい」と解禁するだけで終わらせず、承認済みサービス、データ接続、権限、評価、教育、停止条件まで整え、現場が安全に使い始められる社内の仕組みを設計できるようになります。この記事では、会社が情シスに期待する業務と、業務部門・セキュリティ・法務・経営が分担すべき責任を整理します。
生成AI時代の情シスとは何か：AIツールの配布係ではなく、社内AIプラットフォームの運営者
最初に結論を一言で言うと、生成AI時代の情シスはAIツールを配る部署ではなく、会社の業務とAIを安全に接続し、使える状態を維持し、必要なら止める社内プラットフォーム運営部門です。
日常の例えなら、情シスは「新しい調理器具を全員に配る人」ではなく、社員食堂の厨房を運営する人に近い。調理器具の購入、食材の保管、衛生ルール、注文の受付、異物混入時の提供停止までを考える。料理そのものの味を決めるのは各部門ですが、厨房の安全と再現可能な手順がなければ、昼休みは毎日小さな冒険になります。
ここでいう情シスの中心業務は、次の5つです。
- 守る：認証、権限、入力データ、契約、監査、インシデント対応を整える
- つなぐ：承認済みのAIサービスを、社内ナレッジや業務システムへ適切な権限で接続する
- 測る：利用量、費用、品質、安全性、業務成果を同じ台帳で追う
- 育てる：利用者教育、相談窓口、部門支援、ナレッジ更新を回す
- 止める：危険な利用、予算超過、障害、モデル変更、契約終了時に安全に停止する
ただし、情シスがすべての業務責任を引き取るわけではありません。AIが出した回答を業務上採用するか、顧客へ何を約束するか、採用や人事評価にどう使うかは、それぞれの業務責任者が判断します。情シスは判断の土台と安全装置を提供する、と考えると役割の境界が見えやすくなります。
😓 動機：「生成AIを活用しろ」だけでは、情シスの仕事が無限になる
経営から「生成AIを活用して生産性を上げてほしい」と言われた情シスは、最初に何をすればよいだろうか。チャットAIの契約を結ぶ、全社員のアカウントを作る、社内FAQを検索させる。どれも必要になり得ますが、目的と責任分担がないまま始めると、情シスがAIに関する何でも屋になってしまいます。
一方で、禁止だけを先に出すと、現場は個人契約や未承認サービスへ流れます。いわゆるシャドーAI（会社の審査や管理を経ないAI利用）が増えると、どのデータがどこへ送られたか、誰がどの出力を業務に使ったかを追いにくくなります。全面解禁も全面禁止も、運用としては極端です。必要なのは「安全に使える公式ルート」を用意することです。
個人情報保護委員会は、2023年に生成AIサービスの利用に関する注意喚起を公表しています。これは、生成AIを使うなという一律の結論ではなく、サービスへ入力する情報や利用目的などを確認する必要があることを、会社が具体的なルールに落とすきっかけにすべき資料です。
情シスだけで法的判断を完結させるのではなく、個人情報の責任者、法務、業務部門と一緒に入力可能なデータの範囲を決める必要があります。
さらに、生成AIの効果は利用者や業務によって変わります。高性能なモデルを導入すれば全員の仕事が同じ割合で速くなる、とは限りません。だから情シスに求める成果は「AIの契約を終えた」ではなく、「どの業務を、どの条件で、どの成果指標に結びつけたかを説明できる」ことになります。
🧪 仮説：情シスを「社内AIサービスのプロダクトオーナー」として定義すれば、期待と責任を分けられる
ここで仮説を置きます。情シスをAIツールの購入担当ではなく、社内AIサービスのプロダクトオーナーとして定義すれば、現場の活用と会社の統制を同時に進められるのではないか。
プロダクトオーナーとは、機能を作るだけでなく、誰のどんな課題を解くのか、提供条件は何か、品質をどう測るか、いつ改善・廃止するかを決める役割です。情シスの場合、製品の所有者というより「社内向けサービスの提供責任者」に近い意味で使います。
この仮説から、情シスが提供すべきものを「AIサービスカタログ」として整理します。カタログは、承認済みのAI製品名を並べるだけではありません。対象者、入力可能なデータ、禁止事項、費用負担、ログの扱い、問い合わせ先、停止条件まで書いた利用契約書のようなものです。
🔬 検証：公的ガイドラインは「技術導入」より「関係者が継続的に管理すること」を重視している
このテーマを情シスの都合だけで決めないため、公式資料を横断します。少し込み入った話になるので、コーヒーを用意してほしい。結論は、どの資料も「モデルを入れたら終わり」ではなく、利用者・提供者・開発者など複数の関係者が、リスクと効果を継続的に管理する方向を示していることです。
日本のIPAは、経済産業省・総務省の「AI事業者ガイドライン」について、開発者・提供者・利用者など様々な立場の事業者を対象とするAIガバナンスの統一的な指針と説明しています。また、国際的な議論の変化を踏まえて更新する「Living Document」として、マルチステークホルダーで検討しているとしています。情シスだけで完結しない、という今回の主張と相性がよい考え方です。
米国NISTのAI Risk Management Framework（AI RMF）は、AI製品・サービス・システムの設計、開発、利用、評価へ信頼性の観点を組み込むための、任意利用の枠組みです。NISTは生成AI固有のリスクを特定し、組織の目的や優先順位に合った対策を検討するためのGenerative AI Profileも案内しています。これは、情シスが一枚の禁止規程を配るのではなく、用途ごとにリスクを分類し、対策と評価を台帳化する根拠になります。
CISAのAI Cybersecurity Collaboration Playbookは、AIの提供者・開発者・導入者を含むコミュニティが、AIに関するサイバーセキュリティ情報を共有し、AIシステムのレジリエンスを高めるための協働を扱います。会社内に置き換えれば、情シス、セキュリティ、開発、各業務部門が、事故や脆弱性を自部門だけに閉じ込めない仕組みを持つということです。
EU AI Actでは、Article 4がAIシステムの提供者・導入者に対し、関係者の知識・経験・教育・訓練や利用文脈を考慮したAIリテラシー確保のための措置を求めています。
また、Article 14は高リスクAIシステムについて、利用中に自然人が効果的に監督できる設計を求め、出力を無条件に信頼する自動化バイアスへの注意や、出力を無視・反転する判断、停止手段にも触れています。
適用範囲や法的評価は個別に確認が必要ですが、教育と停止権限を「後で考える付属品」にしない方向性は、情シスの設計に取り込めます。
この検証から、情シスの仕事は「導入」ではなく、次のループを社内サービスとして運営することだと整理できます。
📌 注目ポイント：情シスに求める5つの業務と成果物
「守る・つなぐ・測る・育てる・止める」は覚えやすい標語ですが、標語だけでは会議の壁に貼られて終わります。各業務で何を作り、どこまで責任を持つかを成果物に変換しましょう。
| 業務 | 情シスに求めること | 成果物の例 | 情シスだけで決めないこと |
|---|---|---|---|
| 守る | 認証、権限、入力データ、ログ、契約条件を整える | 承認済みサービス一覧、権限表、入力禁止情報、監査方針 | 法的な適法性、業務上の最終判断 |
| つなぐ | 社内ナレッジや業務システムを最小権限で接続する | データ分類表、接続台帳、アクセス経路、更新責任者 | データの意味、業務ルールの正しさ |
| 測る | 利用量だけでなく成果・品質・費用・安全を計測する | KPI台帳、費用レポート、評価セット、改善記録 | 成果目標の優先順位、業務価値の確定 |
| 育てる | 利用者が限界と使いどころを理解できる状態を作る | 利用ガイド、研修、相談窓口、FAQ、事例集 | 各部門の業務教育、出力の採用判断 |
| 止める | 危険な利用や障害時に、権限縮小・停止・復旧を実行する | 停止条件、連絡網、復旧手順、再審査記録 | 事業影響の最終判断、対外説明、法的対応 |
特に重要なのは「止める」です。導入会議では、使える機能の話が盛り上がります。しかし本番運用では、誤った出力、想定外のデータ参照、API費用の急増、モデル更新による品質変化が起こり得ます。止める権限と連絡先が決まっていないサービスは、アクセルだけ付いた車と同じです。試乗は楽しくても、駐車場へ戻れません。
AIサービスカタログは「製品名の一覧」ではない
カタログを作るときは、製品名と料金だけでなく、利用条件を一つのサービス定義として書きます。次の表は社内で使う項目の例です。実際の可否や数値は、契約・設定・自社の情報分類を確認して記載します。
| サービス例 | 想定利用者 | 入力できる情報 | 人の確認 | 停止・再審査の条件 |
|---|---|---|---|---|
| 承認済みチャットAI | 全社員 | 公開情報・社内規程の範囲内の一般情報 | 業務利用前に利用者が確認 | 契約変更、情報管理条件の変更、重大な誤出力 |
| 社内ナレッジ検索 | 許可された部門 | 利用者の権限で参照可能な文書 | 回答を根拠文書と照合 | 権限漏れ、古い文書の増加、回答品質の低下 |
| 議事録・文書要約 | 会議主催者 | 分類済みの会議資料・音声 | 公開・配布前に担当者が確認 | 機密区分の誤判定、保存先の変更 |
| 開発支援AI | 開発チーム | 許可されたリポジトリとコード | レビューとテストを必須化 | 秘密情報混入、品質・ライセンス確認の不備 |
| 定型作業エージェント | 承認された担当者 | 限定された入力・接続先 | 不可逆操作は人が承認 | 異常ループ、権限逸脱、費用上限超過 |
📊 結果：会社が情シスへ依頼すべきものは「導入」ではなく、8つの運用成果物である
5つの業務を具体化すると、経営や各部門が情シスへ依頼すべき成果物が見えてきます。AI導入プロジェクトの完了条件を、アカウント発行ではなく次の8項目に置き換えるのが実務的です。
- AIサービスカタログ：何を誰がどの条件で使えるか
- 利用申請・相談フロー：新しい用途やサービスをどこで審査するか
- データ分類と接続台帳：どのデータを、どの権限で、どこへ接続するか
- リスク別の自動化基準：提案だけにするか、人の承認後に実行するか
- 評価とKPIの台帳：成果、品質、費用、安全性を何で測るか
- 教育・相談の仕組み：利用者が迷ったときに誰へ聞けるか
- インシデント対応手順：誤送信、権限逸脱、キー漏えい、サービス停止にどう対応するか
- 変更・廃止手順：モデル更新、契約更新、利用縮小、停止をどう記録するか
ここでいう「リスク別」とは、AIという名前だけで一括判定することではありません。たとえば、公開情報を要約する作業と、顧客への返金を実行する作業では、同じチャットAIを使っていても失敗時の影響と取り消しやすさが違います。
| 業務の性質 | 推奨するAIの役割 | 情シスの制御 | 業務部門の責任 |
|---|---|---|---|
| 低リスク・高頻度・やり直しやすい | 定型処理の自動実行候補 | 範囲、上限、ログ、異常停止 | 成果と例外条件の定義 |
| 中リスク・文脈依存 | 回答案・要約・分類の提案 | 根拠表示、権限、レビュー導線 | 内容の確認と採用判断 |
| 高リスク・不可逆・対外影響あり | 分析・下書きに限定 | 実行権限を分離し、承認を必須化 | 最終判断、説明責任、例外承認 |
RACI（Responsible、Accountable、Consulted、Informedの頭文字で、実行担当・最終責任者・相談先・報告先を分ける責任分担表）にすると、さらに誤解が減ります。おすすめは、情シスをすべての項目の最終責任者にしないことです。
| 判断事項 | 情シス | 業務部門 | セキュリティ・個人情報 | 法務・コンプライアンス | 経営 |
|---|---|---|---|---|---|
| 利用目的と成果指標 | 支援 | 主担当・最終責任 | 相談 | 必要時相談 | 優先順位承認 |
| AIサービスの技術選定 | 主担当 | 要件提示 | 審査 | 契約条件確認 | 予算承認 |
| 入力データの利用範囲 | 技術的に制御 | データの業務目的を定義 | リスク確認 | 法的観点を確認 | 例外を承認 |
| 自動化・実行権限 | 制御を実装 | 業務影響を判断 | リスク評価 | 高リスク時に確認 | 重大案件を承認 |
| AI出力の採用 | 基盤を支援 | 最終判断 | 監視・助言 | 必要時確認 | 重要事項を判断 |
| 事故時の初動と対外対応 | 技術的封じ込め | 事業影響を報告 | セキュリティ対応 | 法的対応 | 最終判断・説明 |
KPIは「使われた回数」から「安全に業務成果へ届いたか」へ
利用回数や生成文字数は、運用状況を知る補助指標にはなります。しかし、それだけでは価値を示せません。情シスが業務部門と合意しておきたいKPIは、次のように複数の面を持たせます。
| 観測領域 | KPI例 | 問い | 悪化時の対応 |
|---|---|---|---|
| 成果 | 処理件数、納期、一次回答までの時間 | 業務結果は改善したか | 対象業務・入力・手順を見直す |
| 品質 | 差し戻し率、レビュー通過率、再作業時間 | 速さと正確さを両立できているか | 人の確認、根拠表示、評価データを強化する |
| 費用 | AI利用料、確認工数、保守工数、部門別費用 | 便益に対する総コストは妥当か | モデル、利用上限、対象範囲を調整する |
| 安全 | 権限逸脱、入力禁止情報、監査未達、停止件数 | 許容できない失敗が起きていないか | 権限縮小、停止、再審査を行う |
| 定着 | 教育完了率、適切な利用率、継続利用率 | 想定した使い方が広がっているか | ガイド、UI、相談窓口、業務設計を改善する |
💡 活用事例：研究結果を「自社の約束」にせず、情シスの評価設計に変換する
生成AIの効果を情シスの業務へ落とし込むとき、外部研究の数字をそのまま自社の目標値にしてはいけません。外部研究は、どんな条件で効果が変わるかを考える材料として使います。
NBERの「Generative AI at Work」は、生成AIベースの対話アシスタントを段階的に導入した5,179人のカスタマーサポート担当者のデータを調べています。研究では、解決件数を時間で割った生産性が平均14％向上し、初心者・低スキル層では34％向上した一方、経験豊富で高スキルの担当者への影響は小さかったと報告されています。ここから「社内ヘルプデスクも14％上がる」とは言えません。むしろ、担当者の経験、問い合わせの種類、ナレッジの状態を分けて測る必要がある、と読めます。
GitHubの公式研究では、GitHub Copilotを使ったグループと使わないグループの開発タスクを比較し、完了率は78％対70％、平均完了時間は1時間11分対2時間41分で、使用グループが55％速かったと報告されています。同じ記事は、品質などについて追加の分析が必要だとも説明しています。したがって、情シスがこの数字を「全社で55％高速化」と宣伝するのは不適切です。開発支援AIを提供するなら、自社のコード品質、レビュー時間、セキュリティ検査、手戻りまで含めて再測定します。
この二つの事例を、社内情シスの設計例に変換してみます。最初の対象を「低リスクな社内IT問い合わせの回答案作成」に絞り、回答送信は担当者が承認します。情シスは利用環境、アクセス権、ログ、評価データ、費用を担当し、業務部門は正しい回答とエスカレーション条件を決める。4週間程度の試行期間を置くかどうかは自社で決めますが、期間を決めるなら、導入前の比較条件と一緒に記録します。数字だけ借りて、条件を置き忘れると、AIより先に報告書が幻覚を見ます。
🔥 ハマりポイント：情シスへの期待を間違える5つのパターン
情シスの役割を大きく見せすぎても、小さく見せすぎても失敗します。ここでは、症状・原因・対処法の順で整理します。
その1：「まず全社解禁、ルールは後で」の罠
症状は、利用サービスと入力データが把握できず、後から個別に聞き取りを始めることです。原因は、利用者の自由度を価値と勘違いし、公式ルートを用意しなかったこと。対処法は、最初から承認済みサービスカタログと相談窓口を用意し、未承認利用を責める前に安全な代替手段を示すことです。
その2：「情シスが業務の正しさを保証する」の誤解
症状は、AIが作った契約文、顧客回答、財務資料について、情シスへ最終承認が集中することです。原因は、基盤の責任と業務内容の責任を混同していること。対処法は、業務部門を出力の採用責任者としてRACIに明記し、情シスは根拠表示・ログ・権限・停止手段を担当することです。
その3：「人が見るから安全」の名ばかり承認
症状は、承認者が出力をほとんど読まず、AIの提案をそのまま通すことです。原因は、承認時間、確認項目、停止権限、教育が設計されていないこと。対処法は、低リスク業務でも確認項目を定め、高リスク業務では実行権限を分離し、承認者が拒否・差し戻し・停止できる状態にすることです。EU AI Actの高リスクAIに関する人間の監督の考え方も、単に人が画面の前にいることより、理解・介入・停止できることを重視しています。
その4：「利用回数が多いサービスが成功」の取り違え
症状は、チャット回数は増えたのに、処理時間、品質、顧客満足度、確認工数が改善していないことです。原因は、活動量を業務成果の代わりにしたこと。対処法は、導入前のベースラインを取り、利用量と成果を別々に報告することです。たくさん使われた自動販売機が、会社の利益を必ず増やすとは限りません。お菓子の売上だけが伸びている可能性もあります。
その5：「AIガバナンスは情シスだけで完結する」の思い込み
症状は、法務、個人情報、セキュリティ、現場がレビュー会議に参加せず、最後に情シスへ判断が戻ってくることです。原因は、相談先を明確にしないまま、情シスを窓口兼審判兼責任者にしたこと。対処法は、案件のリスクに応じて関係者を呼ぶ仕組みを作り、経営が例外と優先順位を承認することです。IPAがAIガバナンスを様々な立場の事業者とマルチステークホルダーの関与で扱っていることも、この分担の裏付けになります。
🚀 取り込み方：今日・今週・今月で情シスの役割をサービス化する
いきなり全社のAI基盤を完成させる必要はありません。最初の目的は、曖昧な期待を一つの受付票と一つの評価表へ変えることです。
今日（5分）
現在使われている、または使いたいAI用途を一つだけ選び、次の5項目を一行で書きます。実データや秘密情報は入力せず、業務名だけで構いません。
- 対象業務と利用者
- AIに任せる工程と、人が残す工程
- 入力するデータの分類
- 失敗したときの影響と取り消しやすさ
- 改善したい成果指標と、悪化させてはいけない安全条件
ガイドラインの観点を確認する入口として、IPAのAI事業者ガイドライン検討会の説明と、NIST AI Risk Management Frameworkを参照します。
今週
情シス、業務責任者、セキュリティまたは個人情報の担当者で、1枚のAIサービスカタログを作ります。製品名を決める会議ではなく、「誰が、どのデータを、どの操作まで、どんな確認を経て使えるか」を決める会議にします。
次に、利用申請の受付項目とエスカレーション先を固定します。高リスク・不可逆・対外影響のある操作は、最初からAIの自動実行対象にせず、提案と人の承認を分けます。個人情報を扱う可能性がある場合は、個人情報保護委員会の生成AIサービス利用に関する注意喚起を確認し、個人情報責任者や法務の確認を工程に入れます。
今月
低リスクで頻度の高い1業務を選び、導入前のベースライン、AI利用後の成果、品質、費用、安全イベントを比較します。NBERやGitHubの研究結果は目標値としてではなく、測定項目を考える材料として使います。
月末には、継続・拡大・縮小・停止のいずれかを、数字と条件で判断します。たとえば「回答時間は短くなったが、差し戻し率が基準を超えたので対象カテゴリを縮小する」「利用料は想定内だが、確認工数が増えたのでプロンプトとナレッジを改善する」といった書き方です。AI導入の成果発表会を、利用者数の表彰式にしないことがポイントです。
🔄 代替アプローチとの比較：情シス一任でも、現場任せでもない形を選ぶ
会社の規模や成熟度によって、組織の置き方には複数の選択肢があります。大切なのは、名前ではなく、申請・接続・測定・停止の責任が空白にならないことです。
| 方式 | 強み | 弱み | 向いているケース |
|---|---|---|---|
| 現場任せ | 試行が速く、部門の工夫が出やすい | シャドーAI、費用の重複、データ管理のばらつき | 公開情報だけの個人実験。ただし本番業務には条件が必要 |
| 情シス一任 | 基盤・契約・権限を統一しやすい | 業務知識が不足し、審査待ちが長くなりやすい | サービス登録や共通基盤の管理 |
| AI専門組織・CoE | 評価・教育・横展開の知見を蓄積しやすい | 組織新設のコスト、情シスや現場との境界問題 | 複数部門で本格的に活用し、標準化を進める会社 |
| 連邦型ガバナンス（推奨） | 情シスが共通基盤を守り、各部門が業務責任を持てる | RACIと会議体、例外処理の設計が必要 | 全社展開と部門ごとの専門性を両立したい会社 |
小さな会社なら、専任のAI組織を作らなくても構いません。情シスを中心に、個人情報・法務・セキュリティ・業務責任者を案件ごとに呼ぶ小さな審査会でも、責任表と記録があれば運用できます。逆に大企業では、情シスが共通基盤を担当し、部門ごとのAI責任者を置く方が、すべての判断が中央の一つの机に詰まる事態を防げます。
✅ 要点まとめ：情シスへ求めるのは「AIを入れること」ではなく、会社が安全に使い続けられる状態
ここまでの内容を、経営・情シス・業務部門の会話に持ち込める形へ圧縮します。情シスへ依頼するときは「生成AIを導入して」ではなく、次の成果物を指定してください。
- 情シスは、AIツールの配布係ではなく、社内AIサービスの運営者として振る舞う
- 求める業務は、守る・つなぐ・測る・育てる・止めるの5つで整理できる
- 承認済みサービス一覧には、製品名だけでなく入力データ、権限、費用、ログ、停止条件を書く
- AIの出力を業務上採用する責任は、原則として業務部門に残す
- 高リスク・不可逆・対外影響のある操作は、提案と人の承認・実行を分ける
- 利用回数ではなく、成果・品質・費用・安全・定着を同じダッシュボードで見る
- IPA、NIST、PPC、CISAなどの資料は、情シスだけの規程ではなく、関係者が継続管理する仕組みへ翻訳する
- モデル更新や事故に備え、改善だけでなく縮小・停止・再審査の手順を最初から用意する
📅 今後の展望：情シスの仕事は「導入」から「AIサービスのライフサイクル管理」へ移る
AIサービスは、購入時点で完成する固定設備ではありません。モデル、料金、接続先、社内文書、攻撃手法、法制度、利用者の習熟度が変わります。そのため、情シスの仕事は一度の導入プロジェクトから、登録・審査・提供・監視・更新・廃止を含むライフサイクル管理へ移ると考えられます。
IPAの公式ページがAI事業者ガイドラインをLiving Documentとして扱い、更新を検討していることは、ルール自体も変化を前提にしている例です。NISTの生成AIプロファイル、CISAのAIセキュリティ協働、EU AI ActのAIリテラシーと高リスクAIの人間による監督も、技術部門だけでなく利用者・管理者・意思決定者の役割を問う流れとして読めます。
今後、AIが文章を作るだけでなく、業務システムをまたいでタスクを実行する場面が増えるなら、情シスには、権限の最小化、実行前の承認、処理の追跡、異常時の停止、変更後の再評価がさらに求められます。これは「情シスが全部作る」という意味ではありません。AIを組み込んだ業務を、会社の正式なサービスとして受け入れられる状態にする仕事が増える、という意味です。
まとめ：会社は情シスに「AIを買うこと」ではなく「安全に増やせる業務能力」を求める
生成AIの活用を求められた会社が、情シスへ期待すべきなのは、話題のモデルを契約することだけではありません。どの業務に使えるかを受付し、データと権限をつなぎ、成果とリスクを測り、利用者を育て、危険なときには止めることです。
同時に、情シスへ業務部門の最終判断や法務・経営の責任まで押し付けてはいけません。RACIで責任を分け、情シスは共通基盤と運用の品質を担い、業務部門は成果と出力の採用を担う。これが、現場の速度と会社の安全性を両立する現実的な出発点です。
これを読んだあなたは、次の会議で「情シスにAIを導入してほしい」と頼む代わりに、「承認済みサービスカタログ、利用申請、データ分類、KPI、教育、停止条件を含む社内AIサービスを設計してほしい」と依頼できます。生成AI時代に必要なのは、AIを使う勇気だけではありません。安全に使い続け、必要なら止められる会社の仕組みです。
参考文献
- 独立行政法人情報処理推進機構（IPA）「AI事業者ガイドライン検討会」
https://www.ipa.go.jp/disc/committee/expert-group-on-aigfb.html - National Institute of Standards and Technology（NIST）, AI Risk Management Framework
https://www.nist.gov/itl/ai-risk-management-framework - NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（NIST AI 600-1）
https://doi.org/10.6028/NIST.AI.600-1 - Cybersecurity and Infrastructure Security Agency（CISA）, AI Cybersecurity Collaboration Playbook
https://www.cisa.gov/resources-tools/resources/ai-cybersecurity-collaboration-playbook - 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert - European Union, Regulation (EU) 2024/1689（Artificial Intelligence Act）, Article 4 and Article 14
https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng - Erik Brynjolfsson, Danielle Li, Lindsey R. Raymond, Generative AI at Work, NBER Working Paper 31161
https://www.nber.org/papers/w31161 - GitHub, Research: quantifying GitHub Copilot’s impact on developer productivity and happiness
https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/