概念

承認ワークフロー（AI下書き・人承認）

AIが下書きを作り、人が承認した内容だけを正式な台帳に反映する設計パターン。

AIによる自動化と人の最終判断を分離し、AIが直接データを書き換えず、人が承認した内容だけを正式な台帳に反映する設計パターン。誤ったAI出力が実データに影響を与えるリスクを防ぎ、AI導入の信頼性を高める。

背景

AIエージェントの能力が高まるほど、自動処理の範囲を広げたくなるが、読み取り誤りや判断ミスが発生しうる。特に顧客情報・勤怠・予約・議事録・試験成績書などの業務データでは、誤入力が直接的な損害につながる。そこで「AIは下書きを作る」「人間はそれを確認して承認する」という段階を設けることで、AIの効率と人間の責任を両立させる。Kurage製品群では、この境界を運用ルールではなくコードで強制する点が共通している。

代表的な実装例

このパターンは、kurage-products や kurage-repos に登場するKurage製品群で広く採用されている。

kurage-ai-mom（AI議事録作成システム）: 会議の録音からWhisperが文字起こしし、AIが議事録の下書き（概要・決定事項・ToDo・課題・次回）を作る。人が録音と全文を見比べて承認したものだけが確定議事録になる。AIは承認できない設計をコードで強制しており、未承認の下書きはMCP経由でも参照できない。
kurage-crm-agent（入力ゼロCRM）: 日報を投げるとAIが顧客・商談・活動を下書きに起票し、人が1タップで承認。「台帳にAIは直接書けない安全設計」を明示している。
kurage-ai-meishi-analysis（AI名刺解析・名刺台帳）: AIが名刺の12項目を読み取り下書き登録し、人が原本画像と見比べて承認した分だけ台帳へ。承認時の見比べが容易な点も設計上の特徴。
kurage-fillout（申請書記入アシスト）: 様式の空欄を見つけ、分かるところだけを埋めて元の書式のまま返す。AIに文章は作らせず、入るのは今日の日付・保存済みの会社情報・人が書いた値の3つだけ。分からない欄は推測で埋めず空のまま残す。
kurage-kintai（顔打刻つき勤怠システム）: 顔認証の照合はサーバーの決定的コードが正とし、写真証跡を残すことで人の事後確認を可能にしている。
kproofread（化学試験結果報告書の校正・照査）: 測定値、規格値、単位換算値、合否判定は自動変更せず、決定論的な検査を先に実行する。LLMは文章・表・考察の矛盾を指摘する補助機能に留め、指摘は根拠・重要度・対象位置とともに記録される。最終判断は照査者が行い、原本は保存して修正版は別ファイルとして生成する。
kurl2gr（継続記事追加プロダクト）: AIがサイト概要を土台に外部調査して記事の下書きを作るが、顧客サイトへの掲載は管理画面からの手動操作と専用APIに限定される。顧客サーバーには表示専用PHPだけを置き、日次ワーカーによる自動投稿は行わないことで、サイトへの影響を人の承認・操作の内側に閉じている。
kdbagent（DB操作ツール）: 設定で宣言した「表・列・操作」だけを触らせ、宣言していない表・列・削除はブラウザからもMCP経由でも実行できない。読み取り専用モードも用意し、AIエージェントに渡す権限を最小化する（config-declared-scope）。
kurage-hr-post（職務管理）: 職（ポジション）ごとの達成率はコードが決定的に計算し、AIに採点させない。担当者が代わっても記録が職に紐づいて残る。
kurage-line-crm（LINE窓口）: 顧客へ送るツールは取り消せず通数も消費するため既定で無効にし、環境変数で明示的に有効化したときだけ現れる。参照専用モードも同様に用意されている。
kseo（SEO診断）: 判定はすべて決定論的で、AIの推測を入れない。指摘ごとに実測値と対応を並べた診断書を出力する。
防災系（kurage-disaster-judgment-set / kurage-flood-hazard-map など）: 避難すべきかの結論は内閣府ガイドラインの警戒レベルに沿った規則で先に出し、AIはその結論を質問に合わせて言い換えるだけで結論を変えない。AIが止まっていても規則の答えは出る。
knintei（要介護認定ナビ）: 要介護度は推計方法の係数が非公開のため判定しない。やらないことを先に決めるのも同じ思想の裏返しである。

設計上のポイント

AIは直接書けない: 台帳・本番サイトへの書き込みは承認操作を通す。AIに書き込み権限を与えない安全設計。CRMエージェントでは「AIは下書きに起票、人が承認」という境界を徹底し、AI MOMでは「関門をコードで強制」する。
決定論的検査を先に実行する: AIの確率的な判断に任せる前に、ルールベースで判定できる項目はコードで検査する（deterministic-core）。kproofreadではLLM登場以前に規格範囲と測定値の整合、必須項目の欠落、単位の表記揺れなどを機械的に照査する。達成率の計算（kurage-hr-post）やSEOの判定（kseo）も同様で、「AIの指摘はあくまで補助」という役割分担を支える。
承認の容易さ: 入力ゼロCRMでは1タップ、名刺台帳では見比べるだけ、議事録では録音と全文の突き合わせ、といった低コスト承認が継続利用の鍵。
未承認データの隔離: 承認されていないAI下書きは、外部ツール（MCPなど）からも参照できないようにする。AI MOMでは「参照できるのは人が承認して確定した議事録だけで、未承認のAI下書きは出ない」設計を採用。
証跡の保存: 写真や元データを残し、承認時に人が確認できるようにする（evidence-traceability）。kproofreadでも原本を保存し、修正版は別ファイルとして生成することで、照査の履歴を追跡可能にしている。
本番への影響経路を人に絞る: kurl2grのように、AIの調査結果が最終的に顧客サイトへ出る経路を管理画面からの手動操作だけにする設計もある。自動化は下書き生成までとし、公開・反映のトリガーは人に持たせる。LINE CRMの送信機能のように、取り消せない・課金を伴う操作は既定で無効にし、明示的な有効化を要求するやり方も同じ発想である。
分からない欄を勝手に埋めない: 申請書記入アシストは不明欄を空のまま残し、防災系・制度系は「区域外」と「データなし」「判定不能」を区別する（unknown-vs-outside-distinction）。推測値で埋めることは、承認の土台そのものを壊すため避ける。
外部事実はサーバー側で裏取りする: 決済の入金記録のように、外部サービスが返す事実をサーバー側で確認してから台帳に記録する。AIの申告をそのまま書き込まない。

まとめ

AIの出力をそのまま信頼するのではなく、「下書き→承認→反映」という段階を組み込むことで、AI導入の障壁を下げつつ、データ品質と説明責任を保つ。「AIは直接書けない」ことをコードで強制し、未承認データを隔離する設計は、AIエージェントが業務システムに浸透する上で重要な原則である。さらに、確率的なLLMに任せる前に決定論的検査を走らせ、最終的な本番反映のトリガーを人手に残すことで、kproofreadやkurl2grのような文書・公開物を扱う領域でも同じ信頼性を実現できる。分からない欄を埋めないこと、取り消せない操作を既定で無効にすること、外部の事実をサーバー側で裏取りすることも、同じ思想から出てくる具体的な作法である。

承認ワークフロー（AI下書き・人承認）

背景

代表的な実装例

設計上のポイント

関連コンセプト

まとめ