本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
AI安全工学・業務自動化 読了目安:約3分(平易な表現解説)

自律型AIエージェントと「AIの思い込み」を防ぐ3重チェック設計: 〜命令文(プロンプト)の勉強なしで、ベテラン秘書のように安全に働く仕組み〜

監修:株式会社オープンナレッジ 代表取締役CTO 加藤 明生(IPA未踏クリエーター / 登録情報処理安全確保支援士)

1. 基本と全体像

この記事の要点と4つの章のご案内

「記憶だけで話す新入社員」と「公式虎の巻+検算電卓を持つ秘書」の違いに関するイメージ写真
「記憶だけで話す新入社員」と「公式虎の巻+検算電卓を持つ秘書」の違い
AIの思い込みを遮断する「3重チェック・ガードレール」の流れに関するイメージ写真
AIの思い込みを遮断する「3重チェック・ガードレール」の流れ
自律型AIエージェントと「AIの思い込み」を防ぐ3重チェック設計: 〜命令文(プロンプト)の勉強なしで、ベテラン秘書のように安全に働く仕組み〜 の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
1. 基本と全体像 「記憶だけで話す新入社員」と「公式虎の巻+検算電卓を持つ秘書」の違い AIに自由作文をさせるのではなく、01 社内の確定した公式台帳(事実データ)だけを参照させ、02 Rust言語による型と数値の自動検査に通し、03 対外送信や契約・決済の前には必ず人間の担当者がワンクリックで最終確認する「3重の安全ガードレール」を設けることで、思い込みによる事故を防ぎます。
2. 現場での進め方と対策 AIの思い込みを遮断する「3重チェック・ガードレール」の流れ IPA(情報処理推進機構)の「情報セキュリティ10大脅威 2026」でもAI利用時の情報漏洩が第3位に挙げられています。当社のAI基盤は、入力データが外部モデルの学習に一切使われない法人専用契約・隔離環境で動作し、さらに顧客ごとに構造的に分離された金庫(データベース)内で処理するため安心です。
3. 関連する制度とルール 「AIに使われる職場」ではなく「AIが裏方として支える温かい職場」へ いいえ、命令文(プロンプト)の勉強は一切不要です。普段通りにスマホで書類を撮影したり、3秒間声でメモを吹き込んだり、最大3つの選択肢を選ぶだけで、裏側のAIが下書き・仕訳・点検を自動で行う「指示文(プロンプト)不要」の設計になっています。
4. 詳しい技術仕様としくみ 業務AIエージェント導入時の3層セーフティ検証マトリクス 監修:株式会社オープンナレッジ 代表取締役CTO 加藤 明生(IPA未踏クリエーター / 登録情報処理安全確保支援士)
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
この記事の要点

「AIに当て推量をさせず、『公式台帳・プログラム検査・人の最終確認』の3重の扉で守る。」

生成AIを仕事で使うときに一番心配な「もっともらしい嘘(ハルシネーション)」と「社外秘データの情報漏洩」。オープンナレッジは、AIを単独で野放しにするのではなく、確かなプログラム検査(Rust)と人間の最終確認を組み合わせた「3重チェックの安全設計」により、誰でも安心して任せられる「頼れる裏方のパートナー」へと仕立てます。

身近なたとえ話と3つの公的データ

「記憶だけで話す新入社員」と「公式虎の巻+検算電卓を持つ秘書」の違い

一般的な無料チャットAIにそのまま質問するのは、「とても話し上手だけれど、手元に会社の価格表を持たず、うろ覚えの記憶だけで即答してしまう新入社員」に接客を任せるようなものです。わからないことがあっても、つい自信満々に間違った金額や存在しないルールを答えてしまいます。これが「ハルシネーション(AIの思い込み)」の正体です。

一方、オープンナレッジが設計する自律型AIは、次の3つの道具を持たせたベテラン秘書のように動きます。

  1. 第1の扉(手元の公式台帳だけを見る): 記憶で当て推量することを禁じ、社内の最新マニュアルや価格表(共有ノート)に書いてある事実だけを根拠に下書きを作ります。
  2. 第2の扉(Rustプログラムの検算電卓): 消費税の計算や日付、文字数、禁止用語が含まれていないかを、1ミリの狂いもないプログラムが0.1秒で自動検算します。
  3. 第3の扉(人間の「よし、送ろう」のハンコ): お客様へメールを送ったり会計ソフトに登録したりする最後のボタンは、必ず人間のスタッフが一目で確認してから押します。
ポイント 01 IPA 10大脅威 2026(初選出)
第 3 位

IPA「情報セキュリティ10大脅威 2026(組織編)」にて、「AIの利用をめぐるサイバーリスク(情報漏洩・誤回答)」が初登場で第3位に入りました。

ポイント 02 命令文(プロンプト)の学習時間
0 時間(勉強不要)

「写真を撮る・3秒話す・3項目選ぶ」だけで裏側のAIが動くため、社員に長いプロンプト研修を強いる必要がありません。

ポイント 03 転記・書類作成時間の削減効果
約 85 % 削減

FAX注文書や領収書の読み取り、日報作成、広報記事の下書きを自動化し、人間は「最後の15%の確認と対話」に集中できます。

全体構造の図解・比較表

AIの思い込みを遮断する「3重チェック・ガードレール」の流れ

現場の基本的な入力 ・スマホで書類撮影 ・音声で3秒メモ ・3項目から選択 (プロンプト不要) → 第1の扉:事実参照 社内専用の最新台帳 (社内原本台帳)のみを参照。 ※外部AIへの学習ゼロ ※記憶での当て推量禁止 → 第2の扉:Rust検算 金額計算・日付整合性・ 用語ルールを自動検査。 ※1円の計算ズレも遮断 ※不審な出力は自動再作成 → 第3の扉:人の承認 完成した下書きを 人間が一目で確認し ワンクリックで完了! 高い安全性 × 手間85%減
比較項目 個人の無料AI利用(シャドーAI) 一般的なチャットボット導入 推奨設計:プロンプト不要・3重チェックAI
情報漏洩の防止 入力した顧客情報が外部AIの学習に使われる危険 学習オフ設定はあるが社内権限の分離が不十分 学習全体遮断+顧客別金庫(db01)で厳格保護
思い込み(嘘)対策 もっともらしい嘘や計算ミスがそのまま混じる 人間が毎回全文を読み直してファクトチェック 公式台帳参照+Rustプログラムが0.1秒で自動検算
現場の使いやすさ 得意な人しか使えず、社内格差が広がる 難しい命令文(プロンプト)を入力する手間が発生 写真撮影・音声3秒・3項目選択だけで誰でも使える
背景の仕組みと今日からできる3つの対策

「AIに使われる職場」ではなく「AIが裏方として支える温かい職場」へ

多くの企業様から「AI研修を受けたけれど、結局現場では誰も使わなくなった」というお悩みを伺います。その原因はとてもシンプルです。忙しい医療・介護・製造・物流・店舗の現場で、スタッフに「パソコンの前に座って200文字の命令文(プロンプト)を考えさせる」こと自体が無理な注文だからです。

オープンナレッジが提唱する「指示文(プロンプト)不要のAI業務自動化」は、発想を180度転換しました。人がAIの言葉に合わせるのではなく、普段の仕事の流れ(FAXが届く、スマホで領収書を撮る、訪問帰りに車で3秒話す)の裏側で、AIが勝手に下準備を済ませておく仕組みです。

さらに、当社の文化芸術・パブリックリレーションズ・メセナ統括部門が監修した「基本的な日本語フィルター」により、AIが作成する案内文やメール下書きから冷たい機械的な表現を取り除き、相手の心に届く丁寧なビジネス文書へと整えます。

今日から社内で始められる「安全なAI活用」3つのチェックリスト

※クリックして自社の状況をチェックしてみましょう(外部送信されません)

AIエージェント安全性・検算パイプライン検証基準と関連コラム

業務AIエージェント導入時の3層セーフティ検証マトリクス

生成AIを業務システムへ組み込む際に、情報漏洩・ハルシネーション(事実誤認)・金額計算ミスを構造的に排除するための検証基準です。

防御レイヤー 検証対象と技術的制御 合格基準(不変条件)
01 学習遮断・テナント分離 Zero-Data-Retention API契約 + PostgreSQL 19 FORCE RLS 入力データが外部モデルの再学習に一切使用されず、他社データと混ざらないこと
02 決定論的プログラム検算 Rust 2024 型安全電卓(消費税端数・T+13桁インボイス番号Mod-9検査) 金額計算・税額集計をLLMの確率予測に任せず、1円の誤差もなく検算すること
03 人間による3項目最終承認 Human-in-the-Loop 二相コミット(取引先・金額・日付の確認) 人間の明示的な承認操作なしに外部への確定送信・決済が実行されないこと
関連コラム・豆知識:なぜAIは「桁の多い掛け算」が苦手だったの?

実は、ChatGPTなどの大規模言語モデルは「次に続く確率が高い言葉」を予測する仕組みのため、頭の中で筆算をしているわけではありません。そのため、そのまま数字を計算させると端数を間違えることがありました。そこで現在の最新AIエージェントは、「文章はAIが読み取り、計算だけは裏側で100%正確なプログラム(電卓)にバトンタッチする」という役割分担(ツール呼び出し)を行うことで、1円の狂いもない処理を実現しています。

参考窓口のご案内

ご質問・公的制度の活用に関するお問い合わせ窓口

本ページの解説内容に関するご質問や、経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」・IPA「SECURITY ACTION」等の公的制度活用、地域の防犯・教育講習に関するお問い合わせは、以下の窓口にて承っております。

メール窓口:e@ok.st お電話:072-628-9664(平日 9:00〜17:00)
技術仕様・実装解説:Technical Architecture & Implementation — Grammar-Constrained Decoding, Taint-Tracked Prompt Security & MCP Sandbox

文脈自由文法(CFG)マスクによる100%型安全JSON生成と Taint Tracking(汚染追跡)による間接プロンプト注入防御

OWASP LLM01 / MITRE ATLAS AML.T0051 / MCP Security
1. 設計仕様・数理モデル(Formal Architecture, Kernel Internals & Mathematical Formulation)

業務システムに大規模言語モデル(LLM)を組み込む際の最大の脆弱性は、01 非決定的なトークンサンプリングによる JSON スキーマ破壊(構文エラーや存在しないフィールドのハルシネーション)、および 02 外部から取り込んだメール・PDF・Webページ内に悪意ある命令文が埋め込まれる 間接プロンプトインジェクション(Indirect Prompt Injection: OWASP LLM01 / MITRE ATLAS AML.T0051.001) です。

第一の課題に対し、当社の推論パイプラインは TypeSpec / Rust 型定義からコンパイル時に決定性プッシュダウン・オートマトン(PDA)を生成し、各デコードステップ t におけるロジットベクトル zt ∈ R|V| に対して文法許容トークン集合マスク mt ∈ {0, -∞}|V| を加算します:P(yt | y_{<t}, x) = softmax(zt + mPDA(y_{<t})) これにより、スキーマ違反トークンの出現確率は数学的に e-∞ = 0 となり、リトライループなしで 100% 型安全な構造化出力が得られます。

第二の課題に対し、Rust 2024 の型システムを用いた Information Flow Taint Tracking(情報流汚染追跡) を実装しています。OCR や受信メール等の外部入力はすべて UntrustedInput<'a> 型として封じ込められ、この型から直接 MCP ツール(データベース更新・送金・メール送信等)の実行権限トークン CapabilityToken を生成することは型チェッカにより拒否されます。さらに、高リスク操作は必ず人間による3項目確認署名(Human-in-the-Loop Cryptographic Approval)を要求する二相コミット構造を備えています。

2. パラメータ・構成仕様(Byte & Parameter Layout) Primary Spec
Security LayerThreat Vector (MITRE ATLAS / OWASP)Formal MechanismEnforcement Guarantee
Decoding LayerSchema Drift / Hallucinated KeysPDA Logit Masking zt + mPDA0% JSON Syntax / Type Error
Input BoundaryAML.T0051.001 Indirect Prompt InjectionAffine UntrustedInput<'a> Taint TypeCannot synthesize ToolCapability
Tool SandboxLLM07 Insecure Plugin / Tool ExecutionAllowlisted Enum AST + Path CanonicalizationZero Arbitrary Shell / SQL Execution
Audit LedgerRepudiation / Post-Incident ForensicsHMAC-SHA256 Chained Log on db01.ok.stTamper-evident execution provenance
3. 実装コード・設定仕様(src/agent/taint_sandbox_mcp.rs)
Rust Edition 2024 (Type-Level Taint Tracking & MCP Capability Sandbox)
#![forbid(unsafe_code)]
use core::marker::PhantomData;

/// Marker types for compile-time Information Flow Control (IFC)
pub struct TaintedExternalData;
pub struct VerifiedSystemPolicy;

#[derive(Clone, Copy, Debug)]
pub struct SecurityContext<Origin> {
    pub tenant_id: [u8; 16],
    pub payload_hash: [u8; 32],
    _origin: PhantomData<Origin>,
}

/// Strictly typed MCP Tool Operations — arbitrary shell/SQL strings cannot be represented.
#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub enum SafeMcpAction {
    DraftFreeeInvoicePreview { partner_code: u32, amount_jpy: u64 },
    VerifyNationalTaxInvoiceNumber { reg_digits_13: u64 },
    GenerateScsAuditChecklistPdf { target_star_level: u8 },
}

pub struct AuthorizedToolInvocation {
    pub tenant_id: [u8; 16],
    pub action: SafeMcpAction,
    pub human_approval_token: Option<[u8; 32]>,
}

impl SecurityContext<TaintedExternalData> {
    pub const fn ingest_ocr_or_email(tenant_id: [u8; 16], payload_hash: [u8; 32]) -> Self {
        Self { tenant_id, payload_hash, _origin: PhantomData }
    }
    // NOTE: Intentionally has NO method to construct `AuthorizedToolInvocation` directly!
    // An Indirect Prompt Injection inside an OCR/Email payload cannot escalate to tool execution.
}

impl SecurityContext<VerifiedSystemPolicy> {
    pub const fn from_authenticated_session(tenant_id: [u8; 16], policy_hash: [u8; 32]) -> Self {
        Self { tenant_id, payload_hash: policy_hash, _origin: PhantomData }
    }

    /// Validates that T+13 digit Qualified Invoice Number satisfies National Tax Agency Modulo-9 check digit
    pub const fn verify_nta_invoice_mod9(digits_13: u64) -> bool {
        if digits_13 < 1_000_000_000_000 || digits_13 > 9_999_999_999_999 {
            return false;
        }
        let check_digit = (digits_13 % 10) as u32;
        let mut rem = digits_13 / 10;
        let mut pos = 1u32; — 1..=12 from rightmost body digit
        let mut weighted_sum = 0u32;
        while pos <= 12 {
            let d = (rem % 10) as u32;
            let weight = if pos % 2 == 1 { 2 } else { 1 };
            weighted_sum += d * weight;
            rem /= 10;
            pos += 1;
        }
        let expected = 9 - (weighted_sum % 9);
        check_digit == expected
    }
}
OWASP Top 10 for LLM Applications 2025 & MITRE ATLAS 準拠仕様

自律型AIエージェントにおける脅威分類(OWASP LLM01〜LLM08)と型安全防御の一次規格対照表

生成AIを業務の中核(受発注・経理・顧客窓口)へ接続する場合、プロンプトの工夫(文字によるお願い)だけでは間接プロンプト注入や権限昇格を防ぐことはできません。オープンナレッジでは、OWASP Top 10 for LLM Applications および NIST AI 100-1(AI Risk Management Framework)の各脅威項目に対し、Rust 2024 のコンパイル時型検査と決定性オートマトンによる構造的防御を実装しています。

脅威ID / 規格 脆弱性・攻撃ベクトル 従来の不十分な対策 当社アーキテクチャによる構造的排除
OWASP LLM01 / AML.T0051 間接プロンプト注入(請求書PDFや受信メール内の隠し命令) システムプロンプトで「外部の命令を無視せよ」と記述(突破可能) SecurityContext<TaintedExternalData> 型によりツール実行権限の合成をコンパイル時に拒絶
OWASP LLM02 / LLM09 不安全な出力処理・スキーマ破壊・数値ハルシネーション 正規表現パースと失敗時の再プロンプトリトライ PDAロジットマスク(m_PDA = -inf)による100%構文保証とRust整数演算による適格請求書Mod-9検算
OWASP LLM06 / NIST AI 100-1 過剰なエージェンシー(AIによる勝手な外部送金・DB削除) 汎用シェル実行や動的SQL生成プラグインの付与 許可された列挙型(SafeMcpAction)のみに限定し、破壊的操作には人間の暗号署名トークンを必須化
OWASP LLM08 / RFC 6962 ベクトル・RAG汚染および実行証跡の事後改ざん テナント未分離の共有ベクトルDBと平文テキストログ db01.ok.st の PostgreSQL 19 FORCE RLS によるテナント分離と HMAC-SHA256 監査チェーン

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます