第1章 目的と背景
本ガイドラインは、i3DESIGNにおけるAI活用を安全かつ効果的に進め、チーム全体の開発体験・品質・スピードを向上させるための共通基盤を定めるものです。
AIはもはや特別な技術ではなく、プロセスの一部として当たり前に存在する要素です。
2025年以降、AIは単なる補助ツールから、リポジトリを横断して自律的にコードを生成・テスト・修正するAgentへと進化しました。この変化は「AIを使うかどうか」だけでなく、AIと協働する環境をどう設計するかという問いを私たちに突きつけています。
したがって本ガイドラインは、どう理解し、どう活かし、どう学びを残すかに加えて、AIが正しく動くための構造をどう設計するかを指針として定めます。
第2章 基本原則 ― 理解の自由と説明の信頼
| 原則 | 内容 |
|---|---|
| 理解と責任 | AIの仕組みと出力の意図を理解し、最終判断の責任を人が負うこと |
| 再現性と共有 | 成果だけでなく、試行・学び・過程を知として残すこと |
| 説明可能性 | どのように活用し、どう判断したかを説明できる状態を維持すること |
| 柔軟性と安全性 | リスクを正しく理解し、活用と制約のバランスを設計すること |
| 継続的改善 | 活用の過程そのものを改善対象とし、学習を文化として組み込むこと |
| 構造による品質支援 | 人の注意力だけに頼らず、仕組みで誤りの検知と一部の自動修正を支えること |
【基本姿勢】
AI活用において私たちは、理解の自由と説明の信頼を両立させる。
内部に向けては自律的に学び、外部に対しては説明責任を果たす。
「使わなければ安全」という排除は、組織の学習機会を失わせ、かえってリスクを増大させる。リスクを正しく理解し、活用の中で学びを得ることこそが、真の安全につながる。
さらに、AI Agentの自律性が高まる時代において、人の判断とHarness（技術的制御構造）の両方で品質を支えるという設計思想を共有する。
この三つ――自由・信頼・構造――を同時に満たすことが、健全なAI文化の基盤である。
第3章 安全性と倫理
AI活用における安全性と倫理は、リスクを排除するためだけのものではない。
理解に基づく自由を成立させるための構造設計であり、私たちはその構造の中で判断し、責任を持ち、学びを積み重ねていく。
3.1 セキュリティと情報管理
AIを活用するうえで取り扱う情報は、ISMS（ISO/IEC 27001）に準拠した情報資産管理の枠組みのもとで運用する。情報の区分に応じた取り扱い基準を定め、組織全体で判断力を共有する。
情報区分と取り扱い基準
| 区分 | 内容 | 取扱いの基本方針 |
|---|---|---|
| 一般情報 | 公開情報、技術検証、社内学習など | 自由に入力・検証可。記録を残して共有を推奨。 |
| 業務関連情報 | プロジェクト・チーム運営・社内ドキュメント | 目的を明示し、必要範囲に限定。出力はレビューを経て共有。 |
| 機密情報 | 顧客情報、契約情報、非公開データ等 | 原則AI入力を避ける。必要な場合は匿名化・承認を得る。 |
ケース例：
- 社内議事録やナレッジ共有は業務関連情報として扱い、アクセス制御された環境で要約生成を行う。
- 顧客要件や契約書ドラフトは、匿名化した構成情報のみに分解して入力する。
Agent時代の情報管理
AI Agentはコードベース全体を読み込んで動作するため、従来の「何を入力するか」という粒度での管理だけでは不十分になる。以下の技術的対策を併用する。
- スコープ制限：
.claudeignore、.cursorignore等の設定ファイルにより、Agentがアクセスするファイル範囲を明示的に制御する - シークレットの分離：APIキー・接続情報等は環境変数やVault系サービスに分離し、リポジトリに含めない
- 学習利用の制御：AI サービスのBusiness/Enterprise契約における学習オプトアウト設定を確認・適用する。契約プランによるデータ取り扱いの差異を理解し、適切なプランを選定する
- AI固有の攻撃面の理解：AI Agentの利用により、従来のソフトウェア開発にはなかった攻撃面が生じる。prompt injection（悪意ある指示の埋め込み）、data exfiltration（Agentを介した情報の意図しない外部送信）、Agentの外部アクセスを利用した攻撃などが知られている。これらのリスクの存在を理解し、Agentの権限設定やアクセス範囲の制御に反映する
3.2 生成物の取り扱いと責任
AIが生成した成果物の扱いは、領域ごとに法的リスクが異なる。
重要なのは、出力そのものよりも「どう扱い、どう説明できるか」である。
| 領域 | 注意点 | 対応 |
|---|---|---|
| 開発 | コード出典・ライセンス混入 | 出典を確認し、理解して採用する |
| デザイン | 既存作品や作風の模倣 | 人が再構成し、独自性を担保する |
| 音声・映像 | 声・外見・キャラクター模倣 | 実在表現は避け、法務確認を経て利用する |
AI Agentの自律性がもたらすリスク：
AI Agentが自律的にコードを生成し、依存ライブラリの追加や技術選定を行う場面が増えている。これにより、従来は人が意識的に行っていた判断——ライブラリの信頼性確認、バージョンの妥当性評価、サプライチェーンの安全性検証——が暗黙的にスキップされるリスクが生じている。
これらの出力品質をコントロールする技術的手段（Harness Engineering等）は今まさに発展途上にあり、すべてを構造的に防ぐことはまだできない。だからこそ、PRを作成・マージするエンジニアが最終的な品質の責任を負う。依存関係の変更、技術選定の妥当性、生成されたコードがプロジェクトの要件に適しているかを確認することは、AI活用の自由と表裏一体の責務である。
職能別指針：
- エンジニア：再利用コードの由来を確認。AI出力を「提案」として扱う。Agent生成コードについては、設計意図との整合とテスト結果をもって判断する。
- デザイナー：生成物を”スケッチ”として活用し、最終表現は人が構成。
- ディレクター：クライアント公開時にリスクを説明できる状態を保つ。
詳細なリスク管理指針はAppendix Aを参照。
3.3 倫理と透明性
AIを活用したことを隠す必要はない。
重要なのは、どのように使い、どう判断したのかを説明できること。
AI利用の明示は、コードの行単位ではなくプロセスレベルで行う。コードの大半がAI生成となる現在、「AI生成箇所のラベリング」よりも「どの工程で・どのような判断のもとAIを活用したか」を記録・説明できることが重要である。
実践例：
- PRの説明欄に「Claude Codeで実装、テストは手動追加、設計判断は〇〇が実施」のように工程レベルで記述
- クライアント納品物にAI生成要素が含まれる場合は、制作プロセスと品質確認の手段を記録
3.4 セキュリティ設計の構造
安全性は個人の注意だけでなく、組織設計と技術的仕組みの両方で支える。
| 層 | 内容 | 責任主体 |
|---|---|---|
| 個人レベル | 入力内容のリスクを自ら判断できる知識を持つ | 利用者本人 |
| チームレベル | プロンプト・出力・判断経緯を共有し、誤用やリスクを早期検知する | チームリーダー |
| 組織レベル | AIツール利用状況をモニタリングし、方針を継続的に更新する | AI推進委員会・管理責任者 |
| Harness（技術）レベル | CI/CD、linter、テスト、Agent設定ファイル等によりAI出力の誤りを構造的に検知し、一部の自動修正を支援する | エンジニアリングチーム |
Harness層は、人のレビュー負荷を軽減しつつ誤りの検知と一部の自動修正を支援するための技術的な制御構造である。詳細は第4章を参照。
3.5 サービス提供元の信頼性
AIサービスを活用する際は、利便性だけでなく、運営主体の信頼性と法的リスクを理解した上で判断する。
評価にあたっては、運営企業の所在地だけでなく、データ処理の実施場所、準拠法、契約上の学習利用条項を個別に確認する。国内運営であっても海外データセンターを利用するケース、またその逆も存在するため、一律の判断基準は適用しない。
評価基準と手順の詳細はAppendix Bを参照。
【第3章の原則】
安全性と倫理は、自由な活用を支えるための構造である。透明性が信頼を生み、人の判断力と技術的な制御構造の両輪が、その基盤となる。
第4章 実務ガイドライン
AIは思考と構造を広げるための拡張機構である。
AI Agentの自律性が高まるにつれ、人の役割は「AIの出力を一行ずつ確認すること」から、「AIが正しく動く環境を設計し、結果を検証すること」へと移行しつつある。
4.1 原則 ― 理解を前提とした自由
AI活用の理解とは：
- 動作の理解：どのように動くかを把握する
- 出力の妥当性判断：目的に対して適切かを見極める
- 意図と結果の整合：自分の意図に沿っているかを確認する
4.2 品質へのアプローチの転換
AI Agentの生成スピードは人のレビュー速度を大きく超えており、従来の「人がすべてのコードをレビューする」モデルは持続しない。レビュー工程はすでにボトルネックであり、AI自身をレビューに活用しなければ立ち行かない状況にある。
一方で、前工程の誤りが後工程で複利的に膨らむ構造は、AI時代においても変わっていない。AIが生産速度を加速させた分、前工程の品質が低ければ負債の蓄積速度も加速する。設計の誤りは後工程での検出が困難であり、最も影響が大きいリスクである。したがって人間の役割は、後工程での逐一確認から、前工程での設計・制約の整備へとシフトすべきである。設計に重心を置くが、レビューが不要になるわけではない。
ただし、すべての開発に同じ水準の品質保証を求めるわけではない。プロトタイプや使い捨てのツールであれば、厳密なレビューやHarnessを省略して速度を優先することも合理的な判断である。重要なのは、求められる品質水準を案件ごとに見極め、それに応じた手段を選択することである。
この認識のもと、各フェーズの役割を以下のように設計する。
| フェーズ | AI活用の方法 | Harness（技術的制御） | 人が担う判断 |
|---|---|---|---|
| 設計 | 構成提案、要件定義の整理 | — | 意図づけ・優先順位付け・アーキテクチャ判断 |
| 実装 | コード生成（Agent型ツール） | linter、型チェック、Agent設定ファイルによるアーキテクチャ制約 | 設計意図との整合確認 |
| テスト | ケース生成、異常値検出 | CI/CDによる自動テスト実行、カバレッジ計測 | 妥当性・網羅性判断 |
| レビュー | AIによる補助的チェック | カスタムlintルール（修正指示を含む）、静的解析 | 設計意図からの逸脱の有無、最終的な採用判断 |
| ドキュメント | 要約・翻訳・更新 | スキーマ検証、整合性チェック | 背景・前提の補足 |
人が最も価値を発揮するのは、表の上部——設計フェーズでの意思決定とAgent設定（Guide）の整備——である。下流に行くほどHarnessとAIによる自動化の比重を高め、人は例外的な判断に集中する。
Harnessの限界について：
Harnessが検知できるのは構文・型・パターンレベルの誤りが中心であり、意味レベルの誤り（例：仕様を満たしていない、ビジネスロジックが誤っている等）を構造的に検出することには限界がある。AIによるコードレビュー（AI-on-AIレビュー）も、同系統のモデル同士では誤りを共有する可能性があり、検証ではなく補助的なチェックとして位置づける。意味レベルの品質は、仕様に基づくテスト駆動の検証と人による判断の組み合わせで担保する。
失敗許容度に応じたHarness密度の調整：
上記の構造は一律に適用するのではなく、対象システムの失敗許容度によってHarnessの密度と人の関与度を調整する。
| 失敗許容度 | 対象の例 | AI活用のレベル | Harness・レビューの密度 |
|---|---|---|---|
| 高い | 社内ツール、プロトタイプ、検証環境 | Agentに高い自律性を許容 | 基本的なCI/CDとGuideで十分 |
| 中程度 | 一般的なWebアプリ、管理画面 | Agentを活用しつつ要所で人が確認 | 標準的なHarness＋チームレビュー |
| 低い | 金融系・医療系・決済処理等の高信頼性要求システム | 人が主導し、AIは補助 | 厳格なレビュー体制＋強化されたSensor |
この判断基準は案件開始時にチームで確認し、プロジェクトのAgent設定や運用ルールに反映する。
4.3 Harness Engineering ― AIが正しく動く環境の設計
Harness Engineeringとは、AI Agentのモデル以外の部分――設定、制約、フィードバック機構――を設計する技術的規律である。Harnessとは、Agentの入出力と振る舞いを制御する仕組みの総称であり、「プロンプトだけでは対処できない問題を、仕組みで検知・制御する」ことがその本質にある。
Harnessは以下の二つの制御で構成される。
Guides（フィードフォワード制御）― Agentの振る舞いを事前に方向づける
CLAUDE.md、.cursorrules等のAgent設定ファイルにアーキテクチャ制約、依存方向、命名規約、禁止パターンを記述する- プロジェクトごとのコーディング規約を、人が読むドキュメントとしてだけでなくAgentが参照する構造化ファイルとしても整備する
- テンプレート、スキャフォールド、ディレクトリ構成を事前に準備し、Agentの出力に構造を与える
Sensors（フィードバック制御）― Agentの出力を検知し、自己修正を促す
- CI/CDパイプラインでのlint・型チェック・テスト実行（計算的・確定的）
- カスタムlinterメッセージに修正指示を含め、Agentの自己修正ループを強化する（例：エラーメッセージに「〇〇の依存方向を確認してください」と含める）
- 別モデルによるコードレビュー（推論的）
実践指針：
- 新規プロジェクト開始時にAgent設定ファイル（Guide）を作成し、チームで合意する
- Agentが繰り返す失敗パターンを検知したら、Guideとして構造化してフィードバックする
- Guide/Sensorの有効性を定期的にレビューし、改善する
我々はこの領域の先駆者として実践し、得られた知見を組織知として蓄積していく。
【第4章の原則】
理解が自由を生む。AIが正しく動く環境を設計し、その結果に責任を持つことが、AI時代のエンジニアリングである。
第5章 ツールと環境の指針
AIツールの進化は速く、選択肢は増え続けている。重要なのは最新のツールを追い続けることではなく、各ツールの特性を理解し、プロジェクトの要件に応じて適切に使い分けることである。
5.1 ツールのカテゴリと特性
AIツールは用途と自律度によって性質が大きく異なる。一律に扱うのではなく、カテゴリごとの特性を理解して使い分ける。
| カテゴリ | 用途 | ツール例 | 特性・リスク |
|---|---|---|---|
| 汎用チャット型 | 調査、文書作成、壁打ち、学習 | ChatGPT、Gemini、Claude | 入力情報の管理が主なリスク。出力は人が都度判断。 |
| IDE統合型アシスタント | コード補完、インライン提案 | GitHub Copilot、Cursor（補完モード） | 提案を受け入れるか否かの判断は人に委ねられる。 |
| Agent型 | タスク単位の自律実行、複数ファイル変更 | Claude Code、Cursor（Agentモード）、Codex、Devin | Harness設計が不可欠。入出力の粒度が大きく、従来と異なるガバナンスが必要。 |
Agent型ツールに固有の要件：
- Agent設定ファイル（
CLAUDE.md、.cursorrules等）によるGuide設計 - サンドボックスまたは承認モードでの実行
- セッションログの保存（ツール側の機能を活用）
.claudeignore等によるアクセスファイルのスコープ制限- コスト管理：Agent型ツールは自律的に思考ループを回すため、従来のチャット型とは比較にならない速度でAPIトークンを消費する場合がある。利用上限の設定やコストの可視化を行い、想定外の暴走に備える
5.2 新規ツール導入
- 検証・共有・レビューを経て採用
- 提供元の信頼性評価を実施（Appendix B参照）
- Agent型ツールについては、Harness設計の実現可能性も評価基準に含める
5.3 更新プロセス
- 定期的なツール選定と評価
- 再現性と知の還元性を重視した採用基準
- ツール間の役割重複を整理し、チーム内で使い分けの共通認識を維持する
【第5章の原則】
ツールは手段であり、目的ではない。特性を理解し、適材適所で活用する。
第6章 学びの文化と知の蓄積
AI活用によって個人の生産性は上がる。しかし組織としての実力は、個人の学びが共有・蓄積され、再利用可能な形で残って初めて向上する。
本章では、学びを個人に閉じさせず組織知として蓄積するための習慣と仕組みを定める。
6.1 学びの習慣
| 習慣 | 行動例 | 意図 |
|---|---|---|
| 試す | 新機能を小規模に実験 | 探索と思考の多様化 |
| 残す | 結果と気づきを構造化して記録 | 学びの可視化と再利用 |
| 話す | 発見を共有・議論 | 知の再活用 |
| 真似る | 他者の活用を再現 | 再現性の向上 |
| 改める | 方法を見直す | 継続的成長 |
6.2 知の蓄積の仕組み
「残す」を個人の心がけに頼るのではなく、技術的な仕組みとして設計する。
従来のナレッジベースは「誰かが書かなければ腐る」という構造的問題を抱えていた。組織知を持続的に蓄積するためには、以下の要件を満たす仕組みが必要である。
- メンテナンスコストが持続可能であること：人の手動更新に依存しない、または依存度が低い
- 知識が構造化・相互参照されること：散在する情報が関連づけられ、検索・再利用できる
- 蓄積が複利的に価値を持つこと：追加するほど全体の有用性が上がる
- 人が監督・修正できること：自動化されたメンテナンスの結果を人が検証・介入できる
このような要件に対する有力なアプローチの一つとして、LLMを知識基盤のメンテナーとして活用するパターン（LLM Wiki等）が提唱されている。人がraw source（議事録、設計メモ、トラブルシュート記録等）を投入し、LLMがそれを構造化・相互参照・要約して維持する形態である。
組織としての蓄積対象：
- プロジェクトごとの技術判断・トラブルシュート記録の構造化
- AI活用の成功・失敗事例の組織知化
- クライアントワークで得た汎用的な知見の蓄積と再利用
- Harness設計のパターン集（Guide/Sensorの実装例）の蓄積
Harnessへのフィードバックループ：
蓄積された知識は、プロジェクトのAgent設定ファイル（Guide）にフィードバックする。過去の失敗パターンや設計判断が構造化された知識として蓄積され、それが新しいプロジェクトのHarness設計に反映される——この循環が、組織としての学習を加速する。
人が読むドキュメントとの棲み分け：
LLMが維持する知識基盤は、人が読むための整形されたドキュメント（仕様書、運用手順書等）を置き換えるものではない。両者は役割が異なる。
| 種別 | 主な読者 | 目的 | メンテナンス |
|---|---|---|---|
| 人向けドキュメント | 人（チームメンバー、クライアント） | 合意形成、手順の明示 | 人が責任を持って更新 |
| LLMによる知識基盤 | LLM Agent（人も閲覧可） | 知識の蓄積・検索・再利用 | LLMが構造化・更新、人が監督 |
具体的なアーキテクチャ、運用フロー、ツール選定については、実践を通じて知見を蓄積した上で別途実践ガイドとして整備する。
【第6章の原則】
AIは正解を出す装置ではなく、自分の思考を深め、チームの成長につなげる存在である。知の蓄積は心がけではなく、仕組みで支える。
第7章 ガバナンスと責任
AI活用の自由度が高まるほど、その活用が適切であったかを事後に検証し、改善につなげる仕組みが重要になる。ガバナンスは活用を制限するためではなく、活用の質を継続的に高めるための構造である。
7.1 基本原則
- 最終判断の責任は人が負う
- 目的は制御ではなく再現性の確保
- 誤りは改善の起点とする
7.2 リスク管理とレビュー（ISMS対応）
AI活用のリスク評価・改善はISMSのPDCAに基づく。Harness（技術的制御）のレビューもこのサイクルに組み込む。
| フェーズ | 内容 | 担当 |
|---|---|---|
| Plan | 活用範囲とリスクの整理。案件の失敗許容度に応じたAI活用レベルの設定 | 各チームリーダー |
| Do | 活用と判断経緯の記録。Harness（Guide/Sensor）の設計と運用 | 利用者本人・エンジニアリングチーム |
| Check | 四半期レビュー（成功・失敗共有）。Harness設定の有効性評価。コスト使用量の確認（異常検知を含む） | AI推進委員会 |
| Act | 改善策・教育計画の更新。Harnessパターンの組織知化 | 管理責任者 |
Harnessの改善サイクル：
Agentが繰り返し犯す失敗パターンを検知した場合、以下のプロセスで対処する。
- 失敗パターンを記録・分類する
- Sensor（lintルール、テスト）で検知可能か判断する
- Guide（Agent設定ファイル）に制約として追加する
- 改善結果を知識基盤にフィードバックし、他プロジェクトでも再利用可能にする
詳細なチェックリストはAppendix Cを参照。
7.3 教育と文化形成
- 研修は単発ではなく、四半期ごとに改善サイクルとして実施
- 事例共有では「誤用」だけでなく「成功事例」も同等に扱う
- Harness設計のパターン共有を教育プログラムに組み込む
- ガバナンスは監視ではなく、学びの構造として運用する
【第7章の原則】
責任とは統制ではなく、理解を支援すること。ガバナンスは変化を止める仕組みではなく、変化に学ぶ仕組みである。
第8章 クライアントワークと信頼の設計
AI活用は自由と効率の追求であると同時に、信頼を損なわない設計でもある。
クライアントから見たとき、AIを積極的に使うことが「安心」と結びつく状態を目指す。
8.1 基本方針
- 透明性と説明責任による信頼の維持
- 案件ごとに適切なAI活用範囲を判断（第4章の失敗許容度に基づく）
- 判断に迷う場合は関係者と共有し合意形成
8.2 クライアントのAIポリシーとの整合
クライアントによってはAI利用に対する制限・禁止事項を設けている場合がある。案件開始時に以下を確認する。
- クライアントのAI利用ポリシーの有無と内容
- AIツールをクライアントのリポジトリ・インフラに接続する場合の許諾
- 納品物におけるAI生成コードの取り扱いに関する合意
ポリシーが明示されていない場合でも、AI活用の範囲と方法について事前に共有し、合意を得ることを推奨する。
8.3 価値提供としてのAI活用
AIは人の代わりではなく、人の創造性をより高次で発揮するための補助線である。
クライアントは、AI活用を通じてスピード・品質・透明性の両立という価値を受け取る。
| 判断基準 | 内容 |
|---|---|
| 誠実さ | クライアントの目的に沿って活用 |
| 説明可能性 | 活用経緯を明示 |
| 再現性 | 同じ手順で再現できる |
| 記録性 | 指示内容・出力・修正・採用判断を記録 |
8.4 AI生成コードの権利と契約
AI生成コードの著作権は法的に未確定な領域が多い。以下を案件ごとに確認・対応する。
- 契約書においてAI生成物の権利帰属が明確であるか
- 著作権が認められない可能性がある成果物について、クライアントとリスクを共有しているか
- 必要に応じて法務担当に確認する
【第8章の原則】
信頼は「何をしたか」ではなく「どう向き合ったか」で測られる。自由と信頼は相反しない。設計によって両立させる。
Appendix A 生成物のリスク管理指針
A.1 ソフトウェア開発
- ライセンス条項（特にGPL系）の混入に注意
- コード出典を確認し、理解を伴って採用
- 判断がつかない場合は安全側で対応
対応指針：
- 依存ライブラリやコード出典を確認する
- 判断がつかない場合は、安全側（採用しない・再実装）で対応する
- 出力内容をそのままコピーせず、理解を伴って再構成する
A.2 デザイン・ビジュアル表現
- 作風・構図の模倣は著作権・不正競争リスク
- 実在人物・ブランドの表現は肖像・パブリシティ権侵害の恐れ
- 最終成果物は人が調整・再構成すること
対応指針：
- 「参考」や「補助」として活用し、最終成果物は人が再構成・調整する
- 特定の作家・漫画・アニメ作品のスタイルを模倣した生成は避ける
- 出力物を公表・納品する場合は、独自の創作性を確認し、リスクを説明できる状態にしておく
A.3 音声・映像・メディア生成
- 声優・俳優の声真似やキャラクター再現は人格権侵害の可能性
- 合成音声や映像の利用時はライセンス明示を行う
- 商用利用時は法務・管理責任者に確認
対応指針：
- 実在人物やキャラクターを素材に含めない
- 合成音声を使用する場合は、音源・ライセンスの明示を行う
- AIが生成した声・映像素材を商用利用する際は、法務担当または管理責任者に確認する
A.4 共通原則
- 出力・修正・採用経緯を記録
- 公開・納品前に第三者権利を確認
- モデルやデータの出所を理解して選択
AI生成物は新しい表現であっても、法的には既存の規範の上に立つ。理解と責任をもって扱うことが、自由な創作を守る前提である。
Appendix B サービス提供元の信頼性評価基準
AIサービスを導入・継続利用する際は、以下の観点から評価を行う。
B.1 評価項目
| 評価項目 | 確認内容 |
|---|---|
| 運営主体 | 企業の所在地、法的管轄、信頼性 |
| データ処理場所 | データセンターの所在国・リージョン、準拠法 |
| 学習活用方針 | 入力データの学習利用有無、オプトアウト可否、契約プランによる差異 |
| プライバシーポリシー | 個人情報・機密情報の取り扱い基準 |
| セキュリティ対策 | 暗号化、アクセス管理、監査体制 |
| SLA・可用性 | サービス継続性、障害時の対応 |
| Agent対応 | Harness設計の実現可能性（設定ファイル、ログ保存、スコープ制限、承認モード等） |
B.2 評価プロセス
- 初期評価：新規ツール導入時に上記項目を確認
- 記録：評価結果と判断根拠を文書化（AI活用ツール台帳に記録）
- 定期見直し：少なくとも年1回、利用状況とリスクを再評価
- 更新対応：利用規約・ポリシー変更時は速やかに影響を確認
B.3 リスク判断の基準
リスク評価は運営企業の所在地だけで判断せず、以下の三軸で個別に評価する。
| 評価軸 | 低リスク | 中リスク | 高リスク |
|---|---|---|---|
| データ処理場所・準拠法 | データ処理が国内または法的枠組みが明確な地域 | 信頼性の高い海外リージョンだが準拠法の確認が必要 | データ処理場所が不明、または法的保護が不十分な地域 |
| 学習利用条項 | 契約上、学習利用なしが明記 | 学習オプトアウトが可能 | 学習利用の透明性が低い、またはオプトアウト不可 |
| セキュリティ・運営体制 | 第三者監査済み、明確なセキュリティポリシー | セキュリティ対策はあるが監査情報が限定的 | 運営実態不明、セキュリティ対策が不十分 |
利便性だけでなく、信頼性とリスクを理解した上でツールを選択する。評価は一度限りではなく、継続的に見直すことで安全性を維持する。
Appendix C AI活用におけるISMSチェックリスト
AI活用の運用状況を定期的に確認するためのチェックリスト。
C.1 ツール管理
| 項目 | 確認内容 | 実施者 | 頻度 |
|---|---|---|---|
| AIツール登録 | 利用目的・提供元・保存先が明記されている | チーム代表 | 年次 |
| ツール評価 | 信頼性評価（Appendix B）が実施されている | AI推進委員会 | 年次 |
| 権限管理 | 利用者権限が適切に設定されている | 管理責任者 | 四半期 |
C.2 利用記録
| 項目 | 確認内容 | 実施者 | 頻度 |
|---|---|---|---|
| タスク単位の記録 | AI活用の目的・指示内容・採用判断を記録（ツール側のセッションログ機能を活用） | 利用者 | タスク完了時 |
| 機密情報の取扱い | 機密情報がAIに入力されていないか確認 | チームリーダー | 月次 |
| スコープ設定 | Agent型ツールのアクセス範囲（.claudeignore等）が適切に設定されている |
チームリーダー | プロジェクト開始時・変更時 |
C.3 Harness管理
| 項目 | 確認内容 | 実施者 | 頻度 |
|---|---|---|---|
| Guide設定 | Agent設定ファイルがプロジェクトの設計方針を反映している | エンジニアリングチーム | プロジェクト開始時・四半期 |
| Sensor有効性 | CI/CD、lintルール、テストがAgent出力の誤り検知に機能している | エンジニアリングチーム | 四半期 |
| 失敗パターン対応 | 繰り返し発生する問題がGuide/Sensorとして構造化されている | エンジニアリングチーム | 随時 |
C.4 レビューと改善
| 項目 | 確認内容 | 実施者 | 頻度 |
|---|---|---|---|
| リスクレビュー | AI推進チームがレビュー実施 | 管理責任者 | 四半期 |
| 事例共有 | 成功・失敗事例をナレッジベースに記録 | 全利用者 | 随時 |
| 教育実施 | ISMS教育の一環としてAIガイドライン研修（Harness設計を含む） | 管理責任者 | 年次 |
C.5 インシデント対応
| 項目 | 確認内容 | 実施者 | 頻度 |
|---|---|---|---|
| 手順理解 | 誤出力・情報漏えい時の報告経路を理解 | 全社員 | 年次確認 |
| 対応記録 | インシデント発生時の対応を記録・共有 | 管理責任者 | 都度 |
| 改善策実施 | インシデントから得た学びをHarness・ガイドラインに反映 | AI推進委員会 | 都度 |
チェックリストは監視のためではなく、継続的な改善と学びの構造を支えるためのものである。形式的な確認ではなく、実質的な理解と改善につなげることを重視する。