概念

信頼境界（トラストバウンダリ）

AI判断層が認証・数量決定・執行を持たず、最終リスク判断をコード側が握るKurage共通の分離設計。

信頼境界（トラストバウンダリ）とは、Kurageシリーズの判断API群（頭脳）と取引を実行するOSS本体（ボディ）の間に明確に引かれた責任分担ラインのことです。「頭脳はお金に触れない」という原則で、LLMによる判断は提供するが、取引所・ブローカーの認証情報を持たず、注文数量を決めず、注文執行も一切行いません。この境界は取引に限らず、SNS投稿や記事公開、業務台帳への書き込み、試験報告書の合否判定など「書く・実行する・確定する」権限をAIに直接持たせない設計として、Kurageのプロダクト群全体に共通します。各プロダクトのランディングページには「TRUST BOUNDARY」として明示され、kurage-lps・kurage-articles-index・kurage-repos・kurage-productsで一貫して説明されています。

基本原則

Kurageの各README・LP・記事で繰り返し説明される信頼境界は、次の3点に要約されます。

認証情報なし — 取引所やブローカーのAPIキー・認証情報を保持しない
数量決定なし — ポジションサイズやレバレッジを決めない
執行なし — 注文を出さない。実行機能そのものを持たない

加えて「静かなフォールバックはせず、失敗は見える形にする」という誠実性の原則も含まれます。データが足りない場合は捏造せず「足りない」と正直に返す。フォールバックする場合も、別のLLMやテンプレートへ黙って切り替えるのではなく、ai-judgment-backendのルールベースのような決定論的な安全網へ明確に落とすか、明示的なエラーを返します。kcbrainのLPでは「静かなフォールバックはせず、失敗は見えるエラーで返します」と明記され、kfxbrainのREADMEでも「Gemmaが失敗した場合にテンプレートや別LLMへフォールバックせず、明示的なエラーを返します」と規定されています。

LP群・公開READMEでの明示

kurage-lpsに収録された各製品LPでは、この原則が「TRUST BOUNDARY」という独立セクションや「頭脳はお金に触れない」という明確な文言で繰り返し提示されています。たとえばkcbrainのLPには「取引所認証情報なし・数量決定なし・執行なし。静かなフォールバックはせず、失敗は見えるエラーで返します。最終的なリスクゲートはあなたが動かすボディ側（OSSの kfreqai や、OpenAI互換の /v1/chat/completions 経由で接続するNOFXなど）が持ちます」とあり、kfxbrainも同様に「ブローカー認証情報なし・数量決定なし・執行なし」と明記しています。ksbrainは「証券口座には触れません。ポリシー、数量、人間の承認、執行は呼び出し側に残します」としています。kfreqaiのLPも「外部の頭脳は根拠を受け取って判断を返すだけで、取引所認証情報を持たず、注文も実行できません」と説明し、url2brainのLPでは「利用者のSNS認証情報は持たず、管理された投稿先だけを使用します」としています。また、kfinanalystやktajpのLPでは「本サービスは情報提供のみを目的とし、投資助言ではありません」という免責とともに、レポート生成や判断提示にとどまり、注文執行や口座操作を行わないことが明示されています。

この説明はLP群だけでなく、kurage-reposに収録された各リポジトリのREADMEにも同じ設計思想として現れています。公開リポジトリは、判断APIと取引ボディを別リポジトリに分離し、それぞれのREADMEで「どちらが判断を返し、どちらが実行と最終リスク判定を持つのか」を明示しています。

Kurageシリーズでの実装

判断API（頭脳）側

kcbrain（暗号資産判断API）— 「頭脳はお金に触れない。取引所認証情報なし・数量決定なし・執行なし」。LPの「TRUST BOUNDARY」セクションでも、最終リスクゲートは利用者が動かすボディ側（kfreqaiやNOFXなど）が持つと説明
kfxbrain（FX判断API）— ブローカー認証情報を持たず、注文も実行しない。取引ボディから独立して利用できるGemma 4による構造化判断API集で、TradingAgents・FinGPT・AI Hedge Fund・FinRobot・FinMemの知能をFX向けHTTP APIとして公開する。vendor固定の上流知能を呼んでも、返るのはあくまで「判断」だけ。gemmaが失敗してもテンプレートや別LLMへフォールバックせず、明示的なエラーを返す。ランキング系APIは最大40通貨ペアの観測値を扱い、個別シグナルはURLとJSON本文のpair不一致を拒否して誤判定を防ぐ
ksbrain（日本株インテリジェンスAPI）— 発注・証券口座接続・資産運用は行わず、入力された根拠ID以外を判断の出典として返さない。証拠IDを必須化し「判断が参照した入力をIDで返します。存在しないIDは除外し、資料がなければ『証拠不足』と明示」する設計はevidence-traceabilityの実装。J-Quants APIキーがなければHTTP 503を返し、別データを捏造しない。Yahoo Finance等の非公式APIへ黙ってフォールバックしない
kfinanalyst（金融アナリストSaaS）— 会員ごとのウォッチリストを基に日本語マーケットレポートを生成するが、レポート生成のみで投資助言は行わない。X共有はWeb Intentでユーザー自身のXアカウントから行い、サービス側は投稿用のX認証情報を保持しない。ウォレット連携は任意で、将来のx402課金・URLAI特典用にすぎず、未設定でも全機能を利用できる
ktajp（Kurage TradingAgents）— 複数のAIエージェントが独立に評価し、強気/弱気の討論とリスク審査を経て「根拠付きの判断」を返す。判断は根拠とセットで保存され追跡可能だが、証券口座への注文執行や投資助言は一切行わない。課金はbilling.pyがサーバー側で裏取り（x402 / URLAI / PayPal）し、1分析=1クレジット。一般ユーザーの分析はDeepSeek固定で、adminのみ内部設定・課金対象外

これらのAPIは判断結果だけを構造化JSONで返し、金融商品の注文や資産管理には一切関与しません。

取引ボディ（OSS本体）側

kfreqai（暗号資産自動取引ボット）— 注文・認証・ポジションサイズ・リスク制限は本体側（freqtrade）に残る。オープンコア設計で、リポジトリ単体はLLM・GPU・APIキーなしで動き、判断レイヤーはKFREQAI_JUDGMENT_BACKENDでrule_based / x402 / local_llmを切替。現在はpaper trading（dry-run）のみで実資金は動かさない。オーバーヒートフィルタ、ペア単位の入場禁止、ボラティリティでスケールするポジションサイズ、レジーム対応の同時ポジション上限といったリスク管理は本体側に実装される。レジーム認識・リスク指示・ニュース分類・取引後レビュー・仮説研究は差し替え可能なバックエンドとして分離され、ニュースのリスクチェックと流動性サイズチェックはx402/USDCで1コール単位で購入できる。Hyperliquid対応版は非カストディ設計で、資金は利用者自身のHyperliquid口座に置いたまま、サービスには「取引だけ・出金不可」のAgent Walletを委任するだけ——出金という最も強い権限は利用者側に残る
kfxai（FX自動取引ボット）— README冒頭に「AI判断レイヤーは注文API、認証情報、注文数量を持ちません。最終リスク判定はOSS bodyだけが行います」と明記。OANDA接続・方向予測・注文・損切り/利確・スプレッド制限・日次損失制限はOSS本体にあり、地合い分類・リスク指示・取引反省・改善仮説だけが差し替え可能な判断ブレイン。paper / practice / liveの3モードを持ち、liveはOANDA_ENVIRONMENT=liveとKFXAI_LIVE_ACK=I_UNDERSTAND_THIS_USES_REAL_MONEYの同時設定が無いと起動しない
nofx（オープンソーストレーディングターミナル）— 「The model proposes. The runtime disposes.（モデルが提案し、ランタイムが始末する）」。Go製ランタイムが全注文をモデルの届かないハードリスクリミットで制約し、約定直後にストップを取引所側へ設定。ポジション上限・レバレッジ上限・ドローダウン自動クローズ・取引スロットリングを備え、モデルの連続失敗時はsafe modeで新規エントリーを停止。取引所の認証情報は暗号化してローカル保存され、マシン外へ出ない。起動前preflightでモデルアクセス・ウォレット残高・戦略・取引所残高を検証する。日本語コミュニティ版も「ポジションサイズ、レバレッジ、クールダウン、損失保護、レスポンス検証はGoコードが強制」という固定制御を維持し、MEXCペーパートレードで検証できる

この分離により、AIを更新・交換しても取引の安全性を崩さない構造になっています。

業務アプリ製品群（Kurage App Store）での実装

kurage-app-storeで販売される業務アプリ群も、同じ信頼境界の原則を「AIが下書きし、人が承認する」形で適用しています。AIが台帳に直接書き込むことを防ぎ、人の承認を経た分だけが正式データになります。あわせて、AIに触れさせる範囲は設定ファイルやフォルダで宣言され、最終判定（達成率・顔照合・空き枠・入金確認など）はサーバー側の決定的コードが担当するというdeterministic-coreの設計が貫かれています。AIとの接続経路も、同梱のMCPサーバーにより読み取り専用かつ承認済みデータ限定に制御されます（mcp）。

kurage-ai-mom（AI議事録作成システム）— 会議録音をWhisper（whisper.cpp）が文字起こしし、AIが議事録の下書き（概要・決定事項・ToDo・課題・次回）を作成。人が録音と全文を見比べて承認したものだけが確定議事録になります。「AIは承認できない設計」がコードで強制され、同梱のMCPサーバーも読み取り専用で、参照できるのは承認済みの確定議事録だけ。未承認のAI下書きはMCP経由でも外に出ません。音声データもサーバーの外に出ない構成です
kurage-crm-agent（入力ゼロCRM）— 日報を投げるだけでAIが顧客・商談・活動を下書きに起票し、人が1タップで承認。「台帳にAIは直接書けない安全設計」が明記されています。これはapproval-workflowの典型例です
kurage-ai-meishi-analysis（AI名刺解析・名刺台帳）— AIが12項目を読み取り下書きに登録し、人が原本画像と見比べて承認した分だけ台帳へ。AIは名刺台帳に直接書き込めません
kurage-hr-post（職務・目標・引継ぎ管理）— 職（ポジション）を主語に職務・目標・タスクを管理し、後任は前任の記録をそのまま読めます。達成率はコードが決定的に計算し、AIに採点させません
kurage-kintai（顔打刻つき勤怠システム）— ブラウザで顔打刻→写真証跡→丸めない台帳→月次集計→給与ソフト向けCSV。照合はサーバーの決定的コードが正とし、顔データは同意記録＋削除機能つき。AI判断ではなく決定的コードが最終判定を行います
kurage-light-chatbot（AIチャットボット）— sources/フォルダに置かれたMarkdownだけを知識源として回答を生成するRAG構成（rag）。Markdownソースへの書き込みや外部サービスへの投稿権限は持たず、ナレッジ回答の生成に徹します。IPレート制限・質問ログつき
kurage-memo（シンプルメモ）— AIエージェントによる改変を前提にしていますが、データはユーザーごとに完全分離され（tenant-isolation）、他社サービスには預けません
kurage-vibe-groupware-core（社内グループウェア）— 業務アプリは定義ファイル1枚で追加でき、AIにアプリを書かせる手順書が同梱されますが、権限は担当／責任者／管理者の3つで、判定はコードの1か所だけに集約されています
kreserve（予約・受付システム）— 空き枠の判定と予約の書き込みを同じロック内で行い、同時アクセスでもダブルブッキングが起きない決定的な設計。AIエージェントに設定変更を任せる手順書はありますが、変更範囲は設定ファイルに集約されています
kdbagent（データベース管理ツール）— 「宣言した表・列・操作」だけを触らせる設計で、AIエージェント（claude-code）に「顧客の電話番号を直しておいて」と任せても、範囲より外は壊せません。これはまさにconfig-declared-scopeの実装です。MCPサーバー同梱で、読み取り専用モードも用意されています
kbilling・kpaylink・kinvoice（請求・注文・領収書系）— 決済やPDF発行の実行はサーバー側の決定的コードが行い、AIは設置手順の支援に徹します。PayPalの入金はサーバー側で裏取りしてから記録します。領収書PDFも宛先メールアドレスの確認を通った人だけが受け取れます
kcheckit（情報監視システム）— 情報の収集と「関係しそうなものだけを理由つきでメールに知らせる」ところまで。申請などのアクションは人間の判断に委ねます
ktrackgeo（AIアクセス解析）— GPTBotやClaudeBot等のAIクローラーが自社サイトを読んでいるかを測定・診断するだけで、サイトへの書き込みや設定変更は行いません
kcaldav（カレンダー同期）— ユーザー・カレンダー・パスワードは設定ファイルで宣言し、宣言外は触れません。CalDAVで必要な処理だけを素のPHPで実装し、AIエージェントによる変更も同梱の設計マニュアルの範囲内です
kbbs（宣伝OK掲示板）— 投稿に宣伝URLと同一ドメインのメールアドレスを必須とする本人確認ゲートにより、投稿者の実在性をAI判定ではなく決定的に検証します

これらの製品はkappstore-ecosystemとして、ソースコード同梱・AIエージェントで改変拡張可能（ai-modifiable-software）という方針のもと、信頼境界とAIによる改変を両立させています。多くは1ファイルPHP＋SQLite（self-contained-php-app）のため、データベースサーバー不要・FTPで置くだけで動作し、データの管理主体もユーザー自身のサーバーに残ります。AIに改変を任せても、触れてよい範囲は宣言によって制限されるため、判断と実行の分離がソースコードの次元でも保たれます。

OSS日本語導入キット — セルフホスティングによる境界

kurage-app-storeで販売される導入キット群（decap-cms-japanese-kit・billionmail-japanese-kit・freescout-japanese-kit・krayin-crm-japanese-kit・espocrm-japanese-kit）は、WordPress保守・メール配信SaaS・Zendesk/Help Scout・kintone/Salesforceのような月額サービスの代替として、システムをユーザー自身のサーバーに構築するためのキットです。共有レンタルサーバーやVPSにOSSを立て、データを外部SaaSに預けないself-hostingの構成にすることで、「データがどこにあり、誰が管理するか」という信頼境界をユーザー側に引き戻します。日本語UIが無いOSSには翻訳ファイルを提供し、本家へのプルリクエスト提出（oss-japanese-localization）も行われています。

これらのキットには、当社が実際に構築して確認した手順書・環境チェックツール・落とし穴の記録が同梱され、ai-readable-manualとして設計されています。「フォルダごとclaude-codeやcodexに渡せば、AIが手順書を読んで構築まで進めます」——AIエージェントの役割は文書化された手順の範囲内の構築支援に限定され、完成したシステムの運用権限・データ管理権限はユーザー側に残ります。

取引以外への拡張 — 書く・実行する境界

kvtuber（AI VTuber）— エージェント実行VTuberとしてkdeckのAI Agent Taskに実作業を渡し、記事・動画・Gitコミットなどの成果物を得るが、X投稿にAgentReachは使わない（取得専用スコープのため）。YouTube Liveも監督なしの自動配信は禁止され、自動化を有効にしても監視付きの有人運用に限定される
url2brain（URL2AI Publisherの頭脳）— SNS告知文・ブログ記事を生成し、投稿系スキルも持つ。ただし利用者のSNS認証情報は持たず、投稿先はKurage/EXBRIDGEが管理する投稿先に限定される。x402支払いを明示的な投稿許可として扱い、許可が無い限りdraft_readyを返す。つまり「生成の頭脳」と「投稿の実行権」は分離されている
aimediapost（自律メディア公開）— テキスト→音声→BGM→字幕付きMP4→SNS投稿文までを一つのフローで生成し、YouTubeやXへの公開まで行う自律メディアパブリッシング。ただし中央管理型のプラットフォームを持たず、Self-hostable・API-first・MITライセンスで提供されるため、投稿に使うSNS認証情報と公開先は利用者自身の実行環境に保持される。「Your media flow belongs to you」——公開の権限を中央のサービスに預けない形の信頼境界です
kmontage（解説ショート動画生成）— URLを渡すと抽出・台本作成・ナレーション・動画化まで行うが、「それっぽい動画は作らない品質ゲート」を持つ。台本が日本語12シーンでなければ作り直し、汎用的な埋め草や元ネタに忠実でない台本は却下し、それでも忠実な台本にならなければジョブを停止して動画を公開しない。AIに「生成」は任せても、「公開してよい品質か」の最終判断はゲートが握る誠実性の境界です
kseo（日本語サイト向け技術SEO診断）— 対象サイトを自前クローラーで実際にクロールし、タイトル長を全角換算で数えるなど日本語サイト固有の項目も含めて決定論的なルールだけで採点する。言語モデルが登場するのは改善案の文章を書くところだけであり、そこにも実測値しか渡さないため、AIが数字を作る余地がない。日本語サイトのSEO診断にdeterministic-coreを適用した例。利用者が任意のURLを投げるため、名前解決後のIPを見て内部宛てを拒否するSSRFガードを持つ。無料枠と管理者は自社GPUのgemma、有料の実行はdeepseekを使う
kgeo（AI検索最適化診断）— サイトがChatGPTなどのAI検索に理解・引用されやすいかをGEO監査・日本語AEO採点・LLM回答シミュレーションで診断し、改善案を提示する。現在の製品範囲は「監査と提案」までで、修正の自動実行（llms.txt設置・robots.txt修正・PR自動作成など）は「Kurage GEO Pro」として構想段階に留めている。診断ツール自体はサイトへの書き込み権限を持たないという境界です
karchitect（AI設計スタジオ）— 対話で曖昧なアイデアを要件JSONとシステム設計書へ育て、要件・非機能要件・受入条件・データ・外部連携・リスクを更新しながらMarkdown／Mermaid／HTML／PDFを出力する。役割は「実装にそのまま使える設計書」を育てることで、その先のコード実装やシステム運用は行わない。要件定義という上流工程にAIを閉じ込めることで、書かれた設計の最終確認は人が行える構成です
kproofread（化学試験結果報告書の照査システム）— 決定論的ルール・textlint・ローカルGemma 4の3層で報告書を照査し、「測定値を自動変更しない」「規格値や単位換算値を自動確定しない」「合否判定は責任ある照査者が確定する」と明記。原本を保存し、修正版は別ファイルとして生成。対応形式はDOCX・XLSX・PDF・TXT・CSVで、LLMには抽出テキストだけを渡し元ファイルを外部LLMへ送信しない。AI照査を無効にして決定論的な照査だけを実行することもできる。これはapproval-workflowの典型例です
kzabbix（障害調査レポート自動生成）— Zabbixが検知した障害をローカルLLMが調査し、概要・時系列・ログ解析・原因候補・推奨対応をレポート化するが、復旧作業や監視設定の変更は実行しない。推奨対応はレポートで提示するだけです
kurl2gr（URL2GPTResearcher）— サイトの新着記事を自動リサーチ・掲載するが、顧客サイトに置くのは表示用PHP1ファイルだけで、記事の実体はサービス側が保持。サイト側に書き込み権限を置かないため、AIが直接顧客サイトを書き換える権限を持たないという信頼境界の実装になっています。調査は非同期ジョブで成功・失敗を状態として返し、開始時にクレジットを引き当てて失敗したら返却する。日次のワーカーによる自動投稿は行わず、調査は利用者が実行したときだけ動きます
hermesとopenclaw — オーケストレーションとcapabilityの分離。Hermesがタスクの計画・調整を行い、外部システムへの実操作はOpenClawのcapabilityモジュールが担う。これはエージェント層に信頼境界を適用した例で、「決定する役割」と「実行する役割」を異なるレイヤーに分けることで、全自動化でも権限の暴走を構造的に防ぎます

記事インデックスから見る境界設計

kurage-articles-indexは公開された技術解説記事を一覧化したもので、「判断」と「実行」の分離を主題にした記事が複数収録されています。記事群はAIニュース速報、バイブコーディング、AIエージェント基盤、ローカルLLM、自動取引・FinTech、Web3/x402、SEO/Growth運用など多岐にわたりますが、信頼境界はその横断的な設計思想として繰り返し現れます。

判断と執行の分離を主題にした記事

「勝てるbotは売らない ― コードはOSSで全公開、「判断」だけをx402で量り売りする設計」 — ボディをOSS公開し、判断だけをx402で販売する典型例
「NOFXは数値で売買するのか、AIが決めるのか？ペーパートレードで追った判断とリスク制御の境界」 — paper-tradingを通じて判断とリスク制御の境界を検証
「TradingAgents-JPを公開し、判断基盤ksbrainを独立APIにした設計——日本株AIで「画面」と「頭脳」を分ける」 — tradingagents-jpとksbrainの分離
「kfreqaiをhyperliquid対応させた設計——非カストディ委任・1プロセス多テナント執行・kcbrain/kfxbrainのAI判断ゲート」 — kfreqaiの執行部と判断ゲートの分離
「OpenAlice-JPをx402対応AIエージェントにする — Kurage Brain判断ツールをHTTP 402従量課金で組み込んだ話」 — openalice-jpへの判断API組み込み
「FinRobotを日本語ファーストにforkして、Kurage判断API(x402従量課金)を繋いだ — Kurage FinanalystというSaaSになるまで」 — finrobotとkfinanalystの関係
「個人用の日本株AI分析を、マルチユーザーSaaSにした — TradingAgents-JPがKurage TradingAgentsになるまで」 — 個人OSSからSaaS化しても境界が維持される例
「FreqAIボットに「自己反省・自己改良」のLLM3層を実装した — 制約付き仮説DSLと自動バックテストの設計」 — LLMが触れるのは制約付き仮説DSLと自動バックテストの実行のみ。取引ロジックや資金への直接操作は許されず、判断と実行の境界がコード構造に組み込まれています
「Hermes と OpenClaw の役割分担 — orchestration と capability を分離する」 — エージェントスタックでも「計画する役割」と「実行する役割」を分離し、capabilityモジュールだけが外部APIに触れる。信頼境界をエージェントオーケストレーション層に拡張した例

境界の運用・セキュリティを扱う記事

「AIエージェントに仕事を受注させて稼ぐ市場は本当に来ているのか：dealwork.ai登録で見えた実態」 — ai-agent-marketplaceで判断を売買する際にも、実行権限を渡さない境界が前提になる
「AIエージェントに業務システムの改変を任せるなら『触ってよい範囲』を宣言する設計にする」 — config-declared-scopeによる権限範囲の明示と信頼境界の運用
「Kurage Voice-Proの公開APIが直接叩かれた事例から考えるAI OSS運用のセキュリティ」 — 公開APIの信頼境界と認証・監視の重要性を実例から考察
「Hermes AgentにGSC・Google Analyticsを監視させてSEO対策させる方法と、自作Agent Loopへの応用ノート」 — エージェントは監視と提案を行い、実行は限定的な自動化や人間の承認に委ねる。判断と実行の分離をSEO運用に適用した例

なぜ重要なのか

信頼境界はvibe-trading（バイブトレーディング）の実践と深く結びついています。AIの提案を鵜呑みにせず、最終的なリスク判断を人間または検証済みコードが行うという姿勢が、この境界設計に現れています。

また、x402による従量課金と組み合わせることで、「判断を買う」ことと「取引を任せる」ことを明確に分離できます。kfreqaiはニュースのリスクチェックと流動性サイズチェックをx402/USDCで1コール単位で販売しており、外部AIエージェントが「判断だけを買う」経路が実際に存在します。ai-agent-marketplaceでAIエージェントが仕事を受注する場合も、境界があるからこそ「買った判断」と「実行権限」が混ざらず、安全な取引が成立します。

さらにai-judgment-backendの差し替え構造（rule_based / local_llm / x402）は、信頼境界があるからこそ成り立ちます。判断レイヤーが注文権を持たなければ、ルールベース⇔ローカルLLM⇔有料APIを安全に切り替えられます。paper-trading（dry-run）も、実資金の執行と判断が分離されているからこそ意味を持ちます。

agent-executing-vtuberのようにAIに実際の作業を任せる場合も、渡す権限を境界で制御します。X投稿のような「書く権限」はエージェントの道具に直接持たせず、監督下の運用やユーザー自身のアカウント動作に委ねます。エージェントが執行権限を持たないという原則は、ai-agentやlocal-llmの利用でも一貫しています。

mcpは、この信頼境界をAIの「参照経路」にも拡張します。kurage-ai-momとkdbagentに同梱されるMCPサーバーは読み取り専用で、AIエージェントが参照できるのは人の承認を経て確定した議事録だけ、操作できるのは設定で宣言した表・列・操作だけです。未承認の下書きや宣言外のデータは、MCP経由でも外に出ません。またdeterministic-coreにより、達成率の計算・顔照合・空き枠の判定・入金の裏取りのような最終的な事実判定はコードが決定的に行い、AIに採点・照合・確定を任せません。

そして、kurage-app-storeの業務アプリ群やkproofread・kzabbixのような専門システム、kurl2grのようなサイト更新サービス、kmontageの品質ゲート、kseo・kgeoのような診断ツール、karchitectのような設計支援、さらにself-hostingの導入キット群に示されるように、この原則は金融取引を超えて、CRM・名刺台帳・勤怠・予約・データベース管理・試験報告書の照査・障害対応・CMSやグループウェアの運用・コンテンツ公開・SEO/GEO診断・システム設計支援など日常の業務システム全般に拡張されています。AIが「下書き」を生成し、人が「承認」する。AIが「提案」し、コードが「執行」する。データは自分たちのサーバーに置く。このシンプルな分離が、AIエージェント時代の信頼できるシステム設計の基盤となっています。