K2Aフレーム™は著者がこの数年会社のAI推進仕事の中で経験してきた課題を個人で考えた問題解決方法論です。 このフレームワークに関する用語やプロセス定義などに対して著作権を所有するため、利用したい場合は、本ブログのコメント機能を使ってご連絡ください。
1. K2Aフレーム™の目的
業務知識をAIに変換し、人とAIが協働できる組織文化を作る体系的な方法論。
- 「AI Agentを作る事」ではなく、「業務知識をAI化し、成果を出すこと」が目的
- 投資の中心はシステムではなく、人材と知識整備
- 社員の役割は今までの業務「操作者」ではなく、AIにリプレスされる予定のヒューマンリソースではなく、「AI Pilot（伴走者）」へ進化
1.1 よくある経営陣の誤解パタン
- 「AIは魔法ーAI Agentがあれば大量コスト削減・外注削減可能」型の誤解
AIは万能ではなく、「限定領域での支援」が適切
期待値と成果の乖離で「PoC疲れ」に落ち、投資継続が止まり、社内外の信頼を失うリスクが高い - 「AIで人材シフトー流行りのAIツールで既存正社員を新規事業へシフト可能」型の誤解
「AI運用・評価・改善」など新たな役割が発生
現実は「人員削減」より「リプレイス＋高度化」の組み合わせが有効
1.2 よくある現場の誤解パタン
- 「データプラットフォームがないからAI活用が無理」
K2Aシナリオカード・手順カードがすでに"データの最小単位"。
つまり「まず業務をカード化すること自体がデータ化の入口」になる。
SharePoint/Notion/Confluence/Google Driveにカードを整理して「人とAIの共用リポジトリ」にする。
これが「疑似データプラットフォーム」になる。 - 「APIがないからAI Agentが動く環境がない」
Excel・チャット・ワークフローシステムのログ、承認メール――すべてが"半構造化データ"。
APIがなくてもCSVエクスポート、RPAでスクレイピング、フォーム入力のログなど、既存の出口を探す
K2Aを回すうちに「ここは毎回手入力がダルい」→「じゃあ簡単なAPIつけよう」と後追いで必要性が出る。
2. ブランド定義
- 名称：K2Aフレーム™(Knowledge-to-AI Framework)
- タグライン：業務知識をAIへ、人を未来へ / Turning Knowledge into AI, Empowering People
3. K2A循環プロセス™
Capture(業務知識を捕捉) -> Structure(知識を整備) -> PromptOps(プロンプト設計・運用) -> Evals(評価・検証) -> Adopt(業務導入) -> Refine(改善・再登録) -> 再びCaptureへ
| フェーズ | 定義 | 主担当ロール | 補佐ロール | 成果物 |
|---|---|---|---|---|
| Capture (業務知識を捕捉) | 業務知識をカード化し形式知化 | Domain Owner | AI Pilot | 業務シナリオカード |
| Structure (知識を整備) | 知識をAIが扱える形式に整備 | Domain Owner | AI CoE | 手順カード |
| PromptOps (プロンプト設計・運用) | プロンプトを設計・改善し、AIに業務を実行させる | AI Pilot | AI CoE | プロンプトカード及びEvalsカード |
| Evals (評価・検証) | 成功率・HITL率で評価 | AI Pilot | AI CoE, Domain Owner | Evalsレポート |
| Adopt (業務導入) | 実際の業務システムへ導入 | Domain Owner | AI Pilot, AI CoE | 実装環境・運用ガイド |
| Refine (改善・再登録) | 改善・例外処理を再登録し循環 | AI Pilot | Domain Owner, AI CoE | Evalsカード |
4. K2A標準カード
4.1 業務シナリオカード
| 項目 | 説明 | 記入ポイント |
|---|---|---|
| 業務名 | 業務シナリオのタイトル | 「契約条件入力」「顧客提案資料作成」など、誰でも分かる言葉で書く |
| 担当部門 | 業務を主に担当する部署 | 部署名だけではなく、課・チーム単位まで書くと責任範囲が明確 |
| ステークホルダー | 業務に関与する人の役割 | 業務者(やる人)、承認者(判断する人)、チェック者(二重確認)を明示 |
| トリガー | 業務が開始するきっかけ | メール受信、Slack通知、電話受付、システムイベントなど具体的に |
| 入力 | 業務に必要なデータや情報 | 種類(契約書)、形式(PDF/DB)、取得元(顧客、社内DB)を必ず書く |
| 出力 | 業務の成果物 | フォーマット(Excel、JSON、Word)、利用目的(台帳登録、顧客提出)を記入 |
| システム依存性 | データやシステム連携の前提条件 | 既存で接続可能か、追加開発が必要かを明示 |
| ナレッジ(形式知・暗黙知) | マニュアル化された知識＋現場の慣習 | 「形式知＝基準書に記載」「暗黙知＝ベテランが暗黙にやっている処理」 |
| 手順概要 | 業務の大まかな流れ(3〜5ステップ) | 詳細は「手順カード」に任せ、概要だけを例挙 |
4.1.1 シナリオカードサンプル
| 項目 | サンプル1 | サンプル2 |
|---|---|---|
| 業務名 | 契約条件入力 | 顧客提案資料作成 |
| 担当部門 | 営業部営業事務課 | 法人営業 |
| ステークホルダー | 業務者：営業事務担当 一次承認者：営業課長 二次承認者：営業課長 最終承認者：法務部長 | 業務者：営業担当 承認者：営業マネジャー |
| トリガー | 契約書受領(メール添付) | 商談依頼のメール |
| 入力 | 契約書(PDF) 顧客マスター(DB) 金額ルール(基準書) | 顧客要望(メール文面) 過去提案資料 CRM顧客情報 提案資料テンプレート(PPT) |
| 出力 | 契約台帳データ(Excel) 確認レポート(Word) | 提案資料ドラフト(PPT) 要約(メール文面) |
| システム依存性 | SharePointコネクタ：利用可 Salesforce API：利用可 翻訳サービスMCP：未接続 | Salesforceコネクタ：利用可 CRM API：利用可 |
| ナレッジ(形式知・暗黙知) | 形式知：新規顧客は必ず顧客マスターに登録依頼 暗黙知：大口顧客は社長承認が必須 | 形式知：提案フォーマットは統一 暗黙知：同業界は過去事例を流用 |
| 手順概要 | 1 契約書受領 2 契約期間抽出 3 金額確認 4 顧客マスターと照合 5 台帳に登録 | 1 CRMから顧客情報確認 2 過去資料検索 3 顧客要望整理 4 提案資料作成 |
4.1.2 シナリオカードの粒度の基本的な考え方
- 1人の担当者が連続して実行する、5〜30分程度の作業
- 5分未満→原則はカード化せず、ステープに統合。しかし業務上クリティカルならカード化しても良い
- 30分超過→分割を検討する
4.1.3 シナリオカードの粒度の他の例
- 意思決定の単位: ひとつの「承認/却下」が出るところを1単位にする。
- 責任者が変わるタイミング: 部門や担当が切り替わる所を1単位にする。例：営業 → 法務チェック → 上長承認 → 経理、で4単位。
- アウトプットが独立しているか: その工程だけで成果物が見えるか？（報告書、承認記録、送信完了ログなど）の成果物が見える所で1区切りにする。
- 再利用性: ほかの業務でも同じ流れを流用できるなら、それがちょうどいい粒度。例：営業資料の社外ファイル送信 → 研修資料送信でも流用可。
4.2 手順カード
| 項目 | 説明 | 記入ポイント |
|---|---|---|
| ステップ番号 | 順序管理 | 5〜7程度。10を超える場合は業務を分割 |
| 手順内容 | 作業内容の説明 | 動詞で始める(例：「契約書を受領する」「金額を入力する」)。曖昧語(ちゃんと/しっかりなど)は避ける |
| 判断・例外 | 実行の可否や分岐条件の判断基準と例外をまとめて書く (例：金額が1億円以上なら法務部長承認) | 「〜の場合は」「〜でなければ」の形で書く。 |
| ナレッジ | 必要な形式知(規程・マニュアルなど)・暗黙知(慣習・経験)を書く | 「形式知：〜に記載」「暗黙知：ベテランは〜と判断している」など、両方分けて書く |
| AI適合度 | AIで対応可能か | ⚪︎＝AI単独で可能、△＝AI＋人間のチェック、×＝AI不可。根拠をメモするとレビューしやすい |
4.2.1 手順カードサンプル
| ステップ番号 | 手順内容 | 判断・例外 | ナレッジ | AI適合度 |
|---|---|---|---|---|
| 1 | メールにて契約書を受領する | ファイル形式及び基本情報を確認する。 情報不備の場合は、受信先へ必要な情報依頼を連絡する。 | 形式知：契約書チェックリスト_2025.xls、顧客メールテンプレート.doc 暗黙知：紙で印刷して関係者レビュー文化があり | △ |
| 2 | 契約条件を抽出する | サービス内容・開始日・終了日・成果物などを確認する。 英語の場合は、日本語に翻訳する | 形式知：契約基準書_2025.xlsにある抽出ルールを参照 | ⚪︎ |
| 3 | 金額を入力する | 税込・税抜を確認する。1億円を超える場合は、法務承認を申請する | 暗黙知：端数処理は営業判断 形式知：社内ポータルにある法務申請手順URL | △ |
| 4 | 顧客マスターと照合する | 顧客コードが存在すること。ない場合は新規登録 | 形式知：社内ポータルにある顧客コード新規申請手順URL | ⚪︎ |
| 5 | 台帳に登録する | 入力を行い、完了ステータスを確認する。エラーの場合は、台帳エラー処理対応マニュアルを参照し、エラー処理を行う。 | 形式知：契約台帳管理システム利用手順.doc、台帳エラー処理対応マニュアル.doc 暗黙知：毎週土曜日はシステムメンテナンスを行うのため利用不可 | ⚪︎ |
4.2.2 AI適合度の考え方
| 評価ポイント | 項目 | 評価例 |
|---|---|---|
| 入力・ナレッジデータの特性 | 構造化されているか？ | ExcelやDB → ○、手書きメモ → △〜× |
| デジタル化されているか？ | 電子文書 → ○、紙中心 → △ | |
| 機密度・プライバシー | 高すぎると社内AI適用難 | |
| 業務手順の明確さ | ルールベースか？ | 手順が明確 → AI化しやすい |
| 例外の多さは？ | 例外だらけ → △ | |
| 暗黙知に依存していないか？ | ベテランの勘や経験 → ×寄り | |
| 繰り返し頻度 | 日常的・高頻度か？ | 毎日・毎週の業務 → ○ |
| たまにしか発生しないか？ | 年1回の稀タスク → △ | |
| 成果物の評価基準 | 客観的に正解があるか？ | 数値・帳票 → ○ |
| 主観的判断が強いか？ | デザイン・人事評価 → △〜× | |
| リスク・影響度 | 誤りが致命的でないか？ | 社内文書下書き → ○ |
| ミスが重大事故につながるか？ | 法務契約チェック → △〜×、必ずHITL |
4.3 プロンプトカード
- プロンプトカードは、シナリオカードと手順カードのAI Agent実現のためのプロンプトになる。
- シナリオカードと手順カードは親子関係であるため、シナリオプロンプト(親Agent)と手順プロンプト(サブAgent)も親子の階層構造になる。
4.3.1 プロンプトカード
| 項目 | 説明 | 記入ポイント | 例 |
|---|---|---|---|
| Agent名 | 識別しやすい名前（業務名＋処理内容） | 「A1 契約条件抽出Agent」「C1 顧客照合Agent」 | |
| 役割(Role) | Agentが担う業務の責任範囲の定義 | 曖昧にせず、「これしかやらない」を明記 | 「契約書本文から契約期間・金額・支払条件を抽出するAgentです。」 |
| 入力(Input) | そのプロンプトが扱う前提データ | 場所や形式なども記述 | 「契約書本文（テキスト化済み、日本語）」 |
| 指示内容(Instruction) | AIに与える具体的な命令文 | 出力形式やルールを明示、曖昧さを排除、一度にやることを最小限に | 契約基準書_2025.xlsにある抽出ルールを参照し、顧客名を社内マスターを照合し、顧客コードを返す。 |
| 出力形式(Output Format) | 人間確認を挟む→テキストや表形式 機械処理・API連携が前提→JSON 表形式処理・Excel連携が前提→csvやtsv 次もLLMに読ませるだけ→テキスト | {"契約開始日": "2025/10/01", "契約終了日": "2026/09/30", "金額": "15000000", "税込区分": "税込", "支払条件": "翌月末払", "法務承認必要": true} | |
| Few Shotサンプル(Examples) | サンプルを提示することでより高品質な結果が得られる | 入力と出力例を2~3セット。異常系も含まれる | 異常系支払条件が未定の例：{"契約開始日": "2025/10/01", "契約終了日": "2026/09/30", "金額": "15000000", "税込区分": "税込", "支払条件": null, "法務承認必要": true} |
| 制約(Constrains) | 想定外ケースや適用できない範囲 | 適用できない条件や注意点を明記 | 「10万円以上は人間承認が必要」、「土曜日はバックオフィスシステムのメンテナンスのため、登録処理ができない」 |
4.3.2 プロンプト階層イメージ
| カード | Agentタイプ | Agent名 | 役割 | 指示内容 |
|---|---|---|---|---|
| シナリオカード | 親Agent | 契約条件入力 | 契約条件入力業務を統括し、サブAgentを呼び出して、最終出力を統合 | 1 A1契約条件抽出を実行 2 A2 金額判定を実行 3 A3 顧客照合を行う 4 出力を統合し台帳登録用データを作成 |
| プロンプトカード | サブAgent | A1 契約条件抽出 | 契約本文から「サービス内容・開始日・終了日・成果物」を抽出 | |
| プロンプトカード | サブAgent | A2 金額判定 | 金額を解析し、税込・税抜区分と承認要否を判定 | |
| プロンプトカード | サブAgent | A3 顧客照合 | 顧客名を社内マスターと照合し、顧客コードを返す |
4.4 Evalsカード
- Evalsカードは、プロンプトカード(サブAgent)ごとの検証結果を記録するシート
- 個別プロンプトが業務要件をどの程度満たしているかを、小さな単位で可視化する
- 目的は、問題点の特定と改善サイクリ(PromptOps)の実行
| 項目 | 記入ポイント | 例 |
|---|---|---|
| 対象プロンプト | A1 契約条件抽出Agent | |
| テスト件数 | 100件 | |
| 成功率 | AIが正しい答えを出せた割合(客観評価) | 90% 80% |
| HITL率(人間の加入率) | Human-in-the-Loop率。 AIの出力に対して「人間の確認・修正が必要になった割合」(実運用評価) HITL率が低いほど「完全自動化に近い」 | 100%(成功率が高くても全部チェックしている) 20%(成功率が高くなくても現場が８割はそのまま使う運用) |
| エラー内容 | 短く具体的に 原因と影響のセットで書くと改善に直結しやすい 繰り返し出たものを優先 | 判断の誤り：「契約終了日はnullで返った」 出力不備：「必須項目の顧客コードが抜けた」 例外処理不備:「JSONフォーマット崩れ1件で、実行停止」 |
| 評価者 | 契約管理部 山田 | |
| 評価日 | 2025/09/01 | |
| 改善メモ | 今後の活用のためのナレッジ | 日付正規化ルールを追加すればHITL率が20％まで下げられる見込み |
4.4.1 HITL率の実践イメージ
- K2Aが単なる「整理ツール」じゃなく「継続改善ツール」になるので、「K2AループをHITL率改善のPDCA」として扱う
- 導入初期：HITL率 70%（ほぼ人依存）
- 中期：30%まで削減（例外・リスク対応だけ人が見る）
- 長期：「限界点」まで下げる（ここから先は人間判断が残る）
4.5 Evalsレポート
- 複数のEvalsカードを集約し、業務シナリオ全体の評価サマリを示す文書
- 部門責任者や経営層が、AI導入効果や課題を俯瞰できる形でまとめる
- 目的：意思決定支援(横展開、投資判断、リスク管理など)
| 項目 | 記入ポイント | 例 |
|---|---|---|
| 対象シナリオ | 業務シナリオ名 | 契約条件入力 |
| 評価期間 | レポート対象の期間 | 2025年9月第1週 |
| 総合成功率 | 全サブAgentを平均または合算した成功率 | 85％ |
| 主要エラー傾向 | よく出たエラーの種類を2〜3点記載 | 日付抽出失敗(特に令和表記)、顧客名表記揺れによるマスター照合失敗 |
| 改善アクション | 次のステップでやるべきことを簡潔に記述 | 日付正規化ルールを追加、マスターの顧客名の正規化「（株）」→「株式会社」を導入予定 |
| 評価責任者 | まとめた責任者(部門＋氏名) | 契約管理部 部長 山田 |
4.6 各種カードとレポートの関係性
| シナリオカード | Evalsレポート | ||
| 手順カードA1 | プロンプトカードA1 | EvalsカードA1 | |
| プロンプトカードA2 | EvalsカードA2 | ||
| 手順カードB1 | プロンプトカードB1 | EvalsカードB1 | |
| プロンプトカードB2 | EvalsカードB2 | ||
| プロンプトカードB3 | EvalsカードB3 | ||
| 手順カードC1 | プロンプトカードC1 | EvalsカードC1 |
5 K2A人材ロール定義
| ロール | 定義 | 主な役割(R&R) | 成果物 | 必要なノウハウ・スキルセット |
|---|---|---|---|---|
| Domain Owner™ | 業務知識の責任者。 担当業務に最も精通し、その知識・ルール・例外を管理する責任者 | - 業務シナリオカードを作成・更新 - 業務ルール・判断基準・例外条件を明示 - AI導入対象業務の優先度を決定 - KPI設定と成果コミット | - 業務シナリオカード - 整備済み業務フロー（入力/出力定義） - 業務改善KPI | - 業務プロセス設計力 - 現場知識の形式知化スキル - 基本的なAI活用リテラシー - KPI設計・改善指向 |
| AI Pilot™ | 現場でAIと伴走する人 現場でAIを日常業務に組み込み、AIの出力を監督・改善に反映する伴走者 | - プロンプトの試作・改善(PromptOps) -AIの出力を検証し、Evals結果を記録 - 異常や例外を検知し改善提案 - 導入後の業務運用とフィードバック | - プロンプトカード - Evalsレポート(成功率・逸脱率・HITL率) - 改善提案と更新ログ | - プロンプト設計力(PromptOps) - AI出力の評価眼(批判的思考) - 現場業務の理解 - チェンジマネジメント(AIとの協働に適応する力) |
| AI CoE | 専門支援チーム 組織的にAI導入を推進・標準化し、技術・ガバナンス・教育を担う専門組織 | - PromptOpsの標準化を管理 - Evalsの評価基準とフレーム設計 - システム連携・コネクタ実装 -ガバナンス(セキュリティ、AI倫理)作成 - 全社/部門教育と人材育成 | プロンプトライブラリ、評価基準、導入ガイド | - LLMの基礎知識 - RAG・API・システム連携知識 - データガバナンス/セキュリティ - 教育・標準化推進スキル - 組織変革推進力 |
| K2A Coach™ | K2Aフレーム™の思想・プロセスを理解し、組織での導入を支援できる人材。K2A文化の推進者 | K2Aの6フェーズを現場で正しく回すファシリテーション Domain Ownerの業務カード化支援 AI PilotのPromptOpsやEvalsの実践指導 KPIとメトリクスを可視化し、経営層にレポート 抵抗感や心理的障壁を取り除き、AI文化を定着させる | - 導入ロードマップ(部門ごとのK2A導入計画) - ファシリテーションレポート(ワークショップ・改善提案まとめ) - 成熟度評価レポート（ナレッジ整備率・AIカバー率・品質指標の進捗） | - ファシリテーション力（ワークショップ設計と運営、多様な職種の対話を促進する力、議論を「方法論に沿って進める」ガイド力） - コーチング（チーム全体の行動変化を引き出す、個人の心理的抵抗を和らげ、AIへのポジティブな受容を促す） - 評価と改善設計 - LLMの基礎知識 |
6 成熟度を測るメトリクス
K2Aの進捗は、「量」「質」「活用度」の3軸で測る。この3軸を「成熟度レーダーチャート」で可視化すれば、部門ごとの成熟度を簡単に比較できます。
| 目的 | メトリクス | 内容 |
|---|---|---|
| 整備度 | ナレッジ整備率 | 業務のうちカード化済みの割合(%) |
| 活用度 | AIカバー率 | 業務のうちAIに任せられる割合(%) |
| 品質度 | 品質指標 | 成功率・HITL率 |
7 ワークショップと文化浸透
- Playfulな体験型ワークショップで社員が自分の業務をカード化＆スコアリング
- 「プロンプトバトル」「カバー率ゲーム」などで楽しく指標を体験
- 社員が「AI Pilot™」として自分の役割を理解しやすくなる
8 資格制度
8.1 狙い
- 標準化：バラバラにならず、一定水準のスキル・理解を保証できる
- キャリア価値：個人によって「資格」として残り、モチベーションになる
- エコシステム形成：「K2A認定人材」を増やすことで、方法論が市場標準として広がる
8.2 資格
| 資格 | 目的 | 訓練内容 | 試験内容 | 成果物 |
|---|---|---|---|---|
| Domain Owner Certification | 業務知識を形式知化し、AI導入対象業務を定義できる人材を認定する | - 業務シナリオカード作成演習 - AI導入対象の優先順位付けワーク - KPI設計と評価の実習 | - 記述式：与えられた業務フローをカード化する - ケース試験：AI導入効果をKPIで定義できるか | - 認定証 - ランク制（Associate / Professional / Expertなど） |
| AI Pilot Certification | 現場でAIを活用し、PromptOps・Evals・Refineを回せる人材を認定する | - プロンプト設計ワークショップ（プロンプトカード作成） - Evals演習（成功率・逸脱率・HITL率） - 改善サイクル演習(Refineプロセス実践) | - 実技試験：実際にAIに業務をやらせて、成功率80%以上を達成 - レポート：Evals結果をまとめて、改善提案を出す | - 認定証 - ランク制（Associate / Professional / Expertなど） |
| K2A Coach Certification | - K2Aフレーム™の思想・プロセスを理解し、組織での導入を支援できる人材を認定 - Domain OwnerとAI Pilotを育成と支援し、改善サイクルを回せる「導入コーチ」 | - K2Aフレーム™の体系的理解(思想＋6フェーズ＋メトリクス) - ファシリテーション演習（カード化WS、PromptOpsバトル） - ケーススタディ（導入阻害要因、抵抗の乗り越え方） - KPI改善のストーリーテリング（経営層向け方向演習） | - 記述式：K2Aフレーム™の各フェーズ定義と活用事例説明 - 実技試験：ワークショップをファシリテートして、参加者にカード化・Evalsを成功させる - レポート提出：部門導入計画策定 | - 認定証 |
To be continued
Comments