概念

設定宣言スコープ

設定で許可範囲を宣言し、宣言外への操作・出力・送信を原理的に不可能にする設計パターン。

設定ファイルに「触ってもよい表・列・操作・ユーザー」を明示的に宣言し、宣言されていない対象には一切アクセスできないようにする設計パターン。これはtrust-boundaryの一種で、システム内部の全機能を信頼するのではなく、外部（人間の利用者やai-agent）に委ねる範囲を限定することで、誤操作や悪意ある操作による被害を未然に防ぐ。

背景

近年、Claude Code などのAIエージェントにシステムの改変やデータ操作を任せる機会が増えている。しかし、万能な管理ツール（例: phpMyAdmin）をそのままAIに渡すと、範囲外のデータまで壊されるリスクがある。この概念は、「AIに何をさせてもよいか」をコードではなく設定ファイルとして明示し、AIを含むあらゆる操作主体に対して「守られる境界」を定義する。

この考え方は、Kurageの技術解説記事「AIエージェントに業務システムの改変を任せるなら『触ってよい範囲』を宣言する設計にする」（2026-08-12公開、kurage-articles-indexに収録）でも詳しく解説されており、ai-agentに安全に作業を任せるための実践的なパターンとして広く認知されている。同索引には、AIエージェントに製品を操作させる記事やデモ動画自動生成の記事など、vibe-codingやclaude-codeと組み合わせた安全な自動化の事例が多数収録されており、この設計がその基盤として繰り返し登場する。

Kurage App Store での採用

kurage-products はkurage-app-storeの商品カタログで、無料のAI相談チャットからoss-japanese-localizationの導入キットまで100点近いラインナップが並ぶ。全商品がソースコード同梱・MITライセンスで、AIエージェントによる改変・拡張を前提としている（ai-modifiable-software）。この概念はその共通設計思想であり、買い切り後もユーザー自身が安全にカスタマイズできる商品価値の源泉になっている。

値付けは 5,500円（OSS導入キット）／55,000円／110,000円／165,000円／220,000円／550,000円の6段階で、月額なしの買い切りが原則。価格は実装量ではなく判定を誤ったときに生じる社会的損害の大きさに連動しており（social-impact-pricing）、重要事項説明の下ごしらえ（kurage-juyo-saigai-check、220,000円）や防災判定セット（kurage-disaster-judgment-set、165,000円）、国会会議録を扱うkurage-kokkai-tracker（550,000円）では、宣言の厳格さそのものが商品の中身になっている。カテゴリは防災・ハザード判定、法規制・制度チェック、福祉・介護・子育て、シビックテック・議会、営業・バックオフィス、OSS日本語導入キット、開発中のAI相談チャットに分かれるが、どのカテゴリでも「何を触ってよく、何を外に出してよく、何を言ってよいか」を先に決める型は共通している。

商品群を貫く原則は一貫している。AIは判定の結論を変えず、判定は決定的なコードや規則が行い、人が承認したものだけが確定するという関門をコードで強制する。以下、製品群に浸透している宣言の型を、対象の違いごとに整理する。

操作できる範囲を宣言する

kdbagent — 設定で「表・列・操作」だけを許可。宣言していない表・列・削除はブラウザからもコマンドからも実行できない。同梱のMCPサーバー（HTTPS経由で既存サーバーに繋ぐリモート版含む）により、AIエージェントが「顧客の電話番号を直しておいて」を範囲内だけで安全に実行できる。読み取り専用モードも用意。
kcaldav — ユーザー・カレンダー・パスワードを設定ファイルで宣言。宣言外のカレンダーには触れない。設定変更や機能追加は同梱のClaude Code向け設計マニュアルでAIエージェントに頼める。
kvgwc — 業務アプリを「定義ファイル1枚」を apps/ に置くだけで追加できる。アプリの追加範囲を定義ファイルに限定することで、AIエージェントが勝手にシステム全体を書き換えるリスクを防ぐ。権限は担当（自分の分だけ）／責任者（部署分＋承認）／管理者（全社）の3つで、判定はコードの1か所だけ。
kurage-vibe-cart — 常駐プロセスもポートも要らないPHPのみのECにMCPを同梱し、AIからの商品登録・受注処理を限られた操作として公開する。受注管理は「受注・入金・発送・その他」を個別にチェックする実務的な作り。
kweborder — 取引先はメールアドレスをIDにして自分で登録し、2人目からは招待コードで入る範囲を限定。単価は得意先別の価格・標準単価・取引先の入力の順で決まり、どれを使ったかを記録する。FAX・電話で届いた注文は商社が代理入力でき、受注はCSVで基幹システムに取り込む。PHP 8とSQLiteだけで、レンタルサーバーにフォルダごと置けば動く。
kdealdesk — 顧客台帳を持たず、CSV・API・Webhookでお使いのCRMにメールアドレスでつなぐ設計なので、情報の二重管理が起きない。商談記録と自社の製品・価格・資料（ナレッジ）を根拠にAIが次の提案を考え、使ったナレッジを出典として付ける。打ち合わせメモやメールを貼ると記録の下書き（日付・次にやること・期日）を作り、担当者が承認したときだけ記録に入る（approval-workflow）。
kurage-hr-post — 社員マスタを内部に持たず外部JSONを読むだけなので二重管理にならず、達成率はコードが決定的に計算する（AIに採点させない）。記録を「人」ではなく職に紐づけることで、後任が前任の記録をそのまま読める範囲設計。

変更点を設定ファイルに集約する

kreserve — メニュー・営業時間・定休日・受付ルールを設定ファイルに集約し、Claude Code等のAIエージェントに頼んで安全に変更できる設計マニュアル同梱。空き枠の判定と予約の書き込みを同じロック内で行うためダブルブッキングが起きない。
kpaylink — 価格の決まった商品・サービスの注文ページを「設定ファイル1枚」で立ち上げる。設定に集約することで、そのままAIへの指示書になる。
kcheckit — 監視対象URLを設定ファイルで登録する方式。登録した範囲だけを監視対象とし、それ以外へのアクセスを発生させない。cronが無くてもボタンで動く。
kurage-light-chatbot — sources/フォルダに置くMarkdownが知識範囲を決定し、設定1行でFAQ／社内ChatGPTを切り替える。宣言された設定の範囲内で挙動を変える設計。
kurage-line-crm — 名前・ロゴ・計測タグは設定ファイルで変えられ、書かなければ計測タグは出ない。とくに取り消せず通数も消費するお客様へのLINE送信ツールは既定で無効にしてあり、環境変数で明示的に有効にしたときだけ現れる。参照専用モードも同梱。
kurage-seido-navi — 制度データはJSON 1本。区を選ぶと申請先がその区役所に置き換わり、期限を過ぎた制度は自動で「受付終了」になる。検索にLLMは不要で、2ファイルの差し替えで他自治体へ展開できる（municipality-data-swap-expansion）。
kurage-facilities — 施設ごとにばらばらの個人利用予定表を取り込むが、地域の定義は設定ファイルの差し替えで広げる。検索にLLMは不要で、各行に出典リンクと取得日時が付く。
kposting、kibasho、kecnavi — いずれも初期データ（町田市の掲示場513か所、名古屋市の公表資料、名古屋市16区の窓口）を同梱しつつ、JSONや設定ファイルの差し替えだけで他市区町村に広がる。どこまでを「同梱済み」とし、どこからを「利用者が足す」のかをあらかじめ分けてある。

出力・送信の範囲を宣言する

この宣言は「操作」だけでなく「外に出してよい情報の範囲」にも及ぶ。no-external-data-egressの原則として、製品群に広く共有されている。

kurage-fillout — 申請書にAIが文章を作るのではなく、入るのは今日の日付・保存した会社情報・利用者が書いた値の3つだけ。分からない欄は空のまま残し、ファイルも会社情報も外部へ出さない。MCP同梱。
karchitect — 会話も要件も自分のサーバーの中だけに保存され、外部サービスには出ない。参照資料の添付も同じ境界の内側に閉じる。
kminpaku — 住所を入れると用途地域と上乗せ条例を原文のまま返すが、外部のAIやAPIに住所を送らない。PHP1ファイルとSQLiteだけで動き、条例は原文のまま。
ktoshikeikaku — 住所から用途地域・建ぺい率・容積率等を返すが、判定は自社サーバー内で完結し、条文は原文のまま引用する。PHP1ファイル＋SQLite。
kacnavi — 故人の状況37項目で手続きを絞るが、入力された情報をどこにも送らない。期限はe-Gov法令検索の条文で裏を取り、公開前に34件の引用を検算している。
kouchou-ai-local-kit — アンケート自由記述やパブリックコメントをローカルLLMとローカル埋め込みだけで構造化し、意見データを一切外部に送らない構成を実機検証済み。API費用0円。
住所や入力を扱う他の製品（kchingin、ktoriteki、kseidocal、knisa）でも、計算はブラウザの中だけで行い、入力した時給や取引をサーバーへ送らない。PHP1ファイル・データベース不要という構成が、そのまま境界になっている。

判定・生成の範囲を限定する

kurage-ai-mom — MCPサーバーを同梱し、過去の議事録がAIの調べもの先になる。参照できるのは人が承認して確定した議事録だけで、未承認のAI下書きは出ない。読み取り専用・追加インストール不要。AIは承認できない設計（関門をコードで強制）。
kurage-crm-agent — AIは日報から顧客・商談・活動の下書きを起票するだけで、台帳に直接書き込めない安全設計。宣言による範囲制限とapproval-workflowを組み合わせた好例といえる。
kurage-bill-ai-interview — AIが重ねる質問と「意見のまとめ」を作るが、保存は本人が確かめて同意したときだけ。公開するかどうかも本人が選ぶ。生成AIは手元のモデルで動き、意見を外部のAIサービスに送らない。
kurage-kintai — 照合はサーバーの決定的コードが正で、顔データには同意記録と削除機能が付く。deterministic-coreと範囲宣言の組み合わせ。
kurage-chinjo-navi — 委員会の判定にLLMを使わず、語の一致で選び、何の語で判定したかを画面に出し、当たらなければ「判定できませんでした」と表示する。当てずっぽうで1つ選ばない。陳情の締切日は公表されていないため表示しない。外部APIもLLMも使わず追加費用0円、オンプレミスで動く。
kconsensus — 判定は手元のLLMで行い、外部APIに一度も出さない。読み取りの精度と誤読を画面に表示し、票が足りないときは数字を出さずに「足りない」と書く。
kronten — 国会会議録を素材に論点を立てるが、埋め込みもAIも手元で動き、声を外部に送らない。MCP対応。
kocrwork — すべて自社のサーバーで動き、生成AIもローカルのモデルを選べるので、書類を社外に出さずに使える。OCRエンジンと生成AIの使い方は画面で切り替えられる。
kshuisho — 置いただけなら外部のAIやAPIには何も送らず、文章も作らない。事務所の中のAI（Ollama など）を設定したときだけ、言い換えで探すことと質問主意書の下書きが可能になる。下書きの引用は原文と一字一句照合し、合わないものは出さない。機能の有効化そのものを設定で宣言する型。
kseo — 判定はすべて決定論的で、AIの推測は入らない。タイトルの長さを全角で数えるなど実測に基づき、指摘ごとに実測値と対応を並べた診断書をMarkdownで出力する。
kanketo — 低い評価はその場でメール通知し、AIがひと言のまとめと口コミ返信の下書きを作るが、Googleへの案内は評価に関係なく全員に同じように出す。出力してよい導線をあらかじめ規則で固定し、規約を守る作りにしている。
khisai — 約100の支援制度を内閣府資料の本文のまま一覧にし、AIチャットはその本文だけを材料に答える。被害の程度は規則で先に示す。
kurage-ai-soudan-chat — 補助金・給付金・出店商圏・土地・介護の各AI相談は、候補の絞り込みを規則で行い、AIはその結果を説明するだけという二段構え。判定の範囲と説明の範囲を分けている。
kurage-giin-statement-log、kurage-kokkai-tracker — 議員が「いつ・どの会議で・何を質問したか」を日付と会議名と会議録リンクつきで引くだけで、要約も論評もしない。LLMを使わないので運用費がかからず、議員マスタを変えれば他県でも同じものが作れる。

MCPで参照範囲を限定する

mcpとの親和性も高い。kdbagentやkurage-ai-mom、kurage-vibe-cart、kurage-filloutはMCPサーバーを同梱し、設定で宣言した範囲のデータだけを読み取り専用や限定操作でAIに公開する。kshokenもMCPサーバーを同梱し、読み取り専用・追加インストール不要・標準ライブラリのみで、AIエージェントが商圏の質問に実データで答える。これにより、AIは範囲外に触れる手段すら持たず、「安全に任せられる境界」がより明確になる。kshuishoも同じく、有効化したときだけ設定された範囲のAI機能が現れる。防災・住所系の製品でも、判定エンジンをAIアシスタントやAIエージェントから呼べるMCPサーバー／HTTP APIを同梱しつつ、対象を限っている。

導入キットの手順書

防災・ハザード系の製品（kurage-flood-hazard-map、kurage-tsunami-map、kurage-refuge-map、kurage-morido-map、kurage-disaster-risk-area-map、kurage-disaster-judgment-set、kurage-juyo-saigai-check、kurage-earthquake-map、kurage-landslide-hazard-map）や住所を扱う製品でも、外部の有料APIを使わず、住所を外部サービスに送らないという同一の境界が宣言されている。

導入キット群（decap-cms-japanese-kit、freescout-japanese-kit、espocrm-japanese-kit、krayin-crm-japanese-kit、billionmail-japanese-kit、planka-japanese-kit、vikunja-japanese-kit、docmost-japanese-kit、docspell-japanese-kit、pdfmathtranslate-japanese-kit、codealmanac-japanese-kit、libredesk-japanese-kit、appsmith、paperless-ngx、alaveteli、fixmystreet、theyworkforyou、openvpm）も、AIエージェントに設置を任せる指示書や環境チェックツールを同梱しており、任せられる範囲を手順書という形で宣言している。kbillingやkinvoiceも同様にAIへ渡せる手順書を添えており、この設計が製品全体に浸透している。kurage-memoはAI向けの改造手順書と検証26件を同梱し、kurage-ai-meishi-analysisやkbbsも範囲を定めた運用を前提とする。

AIエージェントとの関係

この概念はai-agentやai-readable-manualと深く結びつく。AIが安全に作業するためには、

許可範囲が設定ファイルとして人間にもAIにも読みやすい形で存在すること
AIがその設定を尊重するように設計マニュアルで指示されていること
設定ファイルの変更自体も同様の範囲制限の対象であること

が必要である。言い換えれば、「操作範囲の宣言」がAIとの間のtrust-boundaryを作り出す。Kurageの記事でも、この宣言を「AIに触らせてよい範囲」として明示し、その範囲内でエージェントが自律的に業務システムを改変できる設計が紹介されている。

また、この考え方はautomationによる業務自動化を安全に進めるための前提条件でもあり、AIエージェントの活用範囲を広げる際に必須のプラクティスとなっている。

なお、宣言の対象は「操作できる範囲」に限らない。判定の結果を「区域外」「未指定」「データなし」に分けて書くというunknown-vs-outside-distinctionの原則も、システムが出力してよい主張の範囲をあらかじめ決めておく点で、同じ発想の延長にある。kgakudoが公表されていない市町村を「未公表」と書き推定値を出さないこと、ktorihikiが確認の要る取引先を上に並べること、kurage-visit-nursing-naviが同名事業所を住所で見分けることも、いずれも「どこまでを確定と言ってよいか」の宣言である。ハザード判定（hazard-map-judgment）や、公表データの有無を明示するadministrative-data-publication-gap、消えた事業所を記録するfacility-data-churn、引用の時点と出典を添えるevidence-traceabilityといったテーマも、「何を言ってよく、何を言ってはいけないか」をあらかじめ決めるという意味で、この概念と地続きである。

実装上の利点

安全性: 宣言外の操作は原理的に実行不可能。
可監査性: 何が許可されているかが設定ファイルを読むだけで分かる。
AI親和性: 設定ファイルがそのままAIへの指示書になる。
簡潔さ: 巨大な権限制御機能を持ち込まず、self-contained-php-appの思想（1ファイル・数百行）と相性が良い。