生成AIやローコードツールの普及により、現場の業務改善（市民開発）のスピードは劇的に上がりました。しかしその一方で、「AIに何でも操作させ、AIの中にナレッジを溜め込めば、業務はいずれ全自動化できる」という幻想が広がっています。
AIの内部（メモリ機能、長大なチャット履歴、ブラックボックスな自律エージェント）に業務ナレッジを溜め込むのは、危険で将来性はあまりない。それはソフトウェア設計における 「ハードコーディング（マジックナンバーの直書き）」と同じです。 初期の立ち上がりこそ速いものの、必ず「なぜAIがこの判断をしたのか分からない」「ルールが変わったのに古い知識が消せない」という巨大な技術的負債となって現場を襲います。
本記事では、AI時代の市民開発者が陥りがちな罠を解き明かし、「あえて人間が手動で介入してでも『差分（Diff）』と『理由（Why）』を外部管理する」ことがなぜ圧倒的な将来性を持つのか、実践的なアーキテクチャとともに解説します。
1. AI時代の市民開発を分断する「3つのレイヤー」
AIが「作業（How）」を秒速でこなせるようになった結果、現場で業務改善やシステム化に関わる人間の立ち位置は、残酷なまでに以下の3つのレイヤーに分断されつつあります。
| レイヤー | 行動原理・スタンス | AI時代の末路・役割 |
|---|---|---|
|
① 考えたくない層 （丸投げ・作業者） |
・「AIに丸投げして、出てきたものをそのまま通したい」 ・判断の根拠（Why）には興味がなく、動けば正義 ・手動での記録や構造化を「面倒な作業」として嫌う |
負債の量産者（最も代替される） ブラックボックスな成果物を量産し、トラブルや監査時に「AIがそう言った」としか説明できず破綻する。 |
|
② 考えることで仕事が残る層 （属人化・職人） |
・「自分の頭の中にある暗黙知や、手動の職人芸に価値がある」 ・自分がチェックしないと品質が保てない状態を守る ・判断基準の言語化・外部化を無意識に恐れる |
組織のボトルネック 個人の能力は高いが、知識が本人の脳内にハードコーディングされているため、業務が永遠にスケールしない。 |
|
③ 考え方を考える層 （市民開発のテックリード） |
・「人間がどこに介入し、何を外部化（SSoT化）すべきか」という構造（ルール） を設計する ・AIを「推論エンジン」として扱い、判断の履歴と理由を管理する基盤を作る |
次世代のアーキテクト 個別の作業をするのではなく、「組織の判断基準が自律的に蓄積・更新される仕組み」をデザインし、価値を爆発させる。 |
私たちが市民開発において目指すべきは、紛れもなく「③ 考え方を考える層」です。
AIに思考を放棄して丸投げする（①）のでもなく、人間の属人的な頑張りに閉じ込める（②）のでもなく、「判断の基準（考え方）をどうやって外部の構造として結晶化させるか」を設計することこそが、これからの市民開発の本丸です。
2. なぜ「AIへの内部蓄積」はハードコーディングなのか？
「AIに過去の資料を全部読ませて覚えさせよう」「AIとのチャット履歴をそのままナレッジにしよう」というアプローチは、一見スマートに見えます。しかし、これはプログラムコードの中に業務ルールや定数を直接書き散らすハードコーディングと構造的に同じ問題を抱えています。
内部蓄積（ハードコーディング）が破綻する3つの理由
-
アンラーニング（忘却と修正）ができない
一時的な対応やあらゆるルールを無秩序に覚えこませますが、不要なルールやルールの変更に対応できないのです。ルールが変わった際に「過去のあの判断基準だけをピンポイントで無効化する」ことが極めて困難になります。古い文脈がゾンビのようにAIの推論を汚染し続けます。 -
「なぜ（Why）」の監査証跡（Audit Trail）がない
厳格な品質管理や審査が求められる業務において、「なぜAという表現をBに修正したのか」という根拠は生命線です。AIの内部にブラックボックスとして溜め込まれた知識からは、事後的に明確な理由を引き出すことができません。 -
AIモデルへのベンダーロックイン
特定のAIツールやモデルの内部にナレッジを育ててしまうと、そのAIプラットフォームの寿命が尽きたとき、あるいはより優秀な別モデルに乗り換えたいときに、業務資産（ナレッジ）を持ち出せなくなります。
AIは「記憶装置」ではなく「ステートレスな関数」として扱え
この問題を解決する原則はシンプルです。AIに「状態（State＝記憶）」を持たせるのをやめ、ナレッジはすべて外部のSSoT（Single Source of Truth：単一情報源） に切り出すことです。
AIは、外部から「今回の入力データ」と「適用すべき判断ルールセット」を受け取り、推論結果だけを返すステートレスな純粋関数として扱います。これこそが、ハードコーディングを脱却し、設定や依存性を外部から注入（DI：Dependency Injection）するモダンな設計思想そのものです。
3. 何を外部化するのか？「結果」ではなく「差分と理由」
では、外部のデータベース（市民開発であれば SharePoint Lists など）に何を記録すべきでしょうか？
多くの人がやりがちな失敗は、「完成した最終版の文書（結果＝What）」だけをフォルダに溜め込むことです。しかし、完成品だけをいくら眺めても、「なぜその記述になったのか（どういうNG表現が、どういう理由で修正されたのか）」という判断基準は読み取れません。
本当に再利用価値があるナレッジとは、審査やレビューの過程で発生する「差分（Diff）」と「理由（Why）」のセットです。
実践モデル：審査・照査ログの「5要素タプル」化
たとえば、現場の計画書や手順書、指図記録マスターなどを起案し、品質保証（QA）や上位者が審査・照査するプロセスを考えます。このとき、AIの処理だけでなく人間の処理であっても以下の5要素を1レコードとしてSharePoint Listsに記録します。
-
State_A（変更前）: 起案時の不十分・不適切な記述 -
State_B（変更後）: 審査を経て修正された正しい記述 -
Reason_Why（理由）: なぜAではダメで、Bにする必要があるのか（原則・根拠） -
Action_Taken（対応）: 実際の修正対応や水平展開の範囲 -
Verification（確認）: 審査者による最終確認とクローズ記録
SharePoint Listsによる「ハイブリッドNoSQL」設計
文書の審査内容は多種多様なため、RDB（リレーショナルデータベース）のようにガチガチに列を正規化すると、入力が苦痛になり運用が破綻します。そこで、SharePoint Listsを「検索用のインデックス列」と「文脈を柔軟に抱えるNoSQL的ペイロード」のハイブリッドとして設計します。
| 構造レイヤー | 列名（例） | 型 | 役割 |
|---|---|---|---|
|
1. インデックス層 （検索・抽出キー） |
DocType（文書種別）ProcessTag（対象工程）RuleCategory（理由分類） |
選択肢 （複数可） |
AIや人間が「今書いている工程に関連する過去ルール」を高速にフィルタリングするためのタグ。 |
|
2. コア・タプル層 （差分と理由の本体） |
State_A / State_BReason_WhyAction / Verification
|
複数行テキスト |
[Aを、Bに変える、理由、対応、確認] の明示的な記録。特に Reason_Why が再利用の核となる。
|
|
3. ペイロード層 （スキーマレス領域） |
ContextPayload |
複数行テキスト （JSON / MD） |
設備固有の前提条件や関連規定番号など、定型列に収まらない背景情報を丸ごと格納するNoSQL的領域。 |
| 4. ライフサイクル層 | RuleStatus |
選択肢 |
Active（有効） / Superseded（廃止・旧版）。 |
「審査側がWrite、開発側がRead-Only」という責務分離（CQRS）
このナレッジ基盤を運用する上で極めて重要なガバナンスが、書き込み（Write）と読み取り（Read）の権限分離です。
-
審査・承認側（QAなど）＝ Write権限:
判断のオーソリティ（権威）を持つ側だけが、リストに[A→B, 理由]を書き込み、確定させます。これにより、「何が正しい判断基準なのか」の純度が100%保たれ、現場の勝手な解釈によるナレッジの汚染を防ぎます。 -
起案・開発側（現場・AI）＝ Read-Only権限:
計画書や手順書を作る側は、このリストを「読み取り専用の外部契約（コントラクト）」として参照します。改ざんリスクがないため、このリスト自体が強力な監査証跡としても機能します。ただしActionについては現場が追記できるようにするのもの良いでしょう。
4. ルール変更に無敵になる「廃止と追記」の運用
この外部化アーキテクチャの真価が発揮されるのが、「前提ルールが変わったとき」 と 「AIによる事前チェック」 の場面です。
1. アンラーニング不要の「イミュータブルな更新」
法改正や社内規定のアップデートで、過去の判断基準が変わったとします。AIの内部に記憶させていた場合は絶望的ですが、SharePoint Listsに外部化していれば作業は一瞬です。
- 古い基準のレコードの
RuleStatusをSuperseded（廃止） に変更する（履歴として残すため削除はしない）。 - 新しい基準に基づく
[A→B, 理由]のレコードをActive（有効） として1行追加する。
これだけで、過去の経緯（監査証跡）を一切損なうことなく、組織のナレッジベースが最新状態に切り替わります。
2. AIへの「理由の動的注入（プロンプトバインディング）」
起案者が新しい計画書や手順書のドラフトをWordやExcelで作成した際、審査へ回す前にAIでセルフレビューを行います。このとき、AIには以下のように指示を出します。
【AIへのプロンプト構造】
あなたは以下の[審査ルールセット]に厳密に従って文書を検査するステートレスな審査エンジンです。
SharePointリストから抽出したRuleStatus = ActiveかつProcessTag = 対象工程のレコード群（JSON/CSV）を以下に与えます。
今回の[新規ドラフト]の中に、過去のState_A（変更前）に類似する記述、あるいはReason_Why（理由）の原則に抵触する箇所がないか検査し、State_B（変更後）への修正案と、その根拠となったルールIDを出力してください。
これにより、AIはハルシネーション（もっともらしい嘘）をつく余地を奪われ、「組織が公式に承認した最新の『理由（Why）』」だけを根拠としてドラフトを検査します。審査に回る前に定番の指摘事項がすべて潰されるため、差し戻しの手戻りループは劇的に減少します。
おわりに：市民開発よ、「構造」をデザインせよ
「AIに全部やらせて、人間は何も考えなくていい」というのは、甘い罠です。それをやればやるほど、現場には誰もメンテナンスできないブラックボックスな負債が積み上がります。
一方で、「人間の職人芸でチェックし続ける」のも限界があります。
AI時代の市民開発者が立つべき場所は、そのどちらでもありません。
「人間がどこで意思決定し、その『差分（Diff）』と『理由（Why）』をどういうデータ構造で外部化すれば、人間もAIも迷わず動けるか」——この「考え方（アーキテクチャ）を考える」ことこそが、現場を知り尽くした市民開発者にしかできない最高のエンジニアリングです。
チャット画面の向こう側のAIに記憶を預けるのはもうやめましょう。私たちの業務の「理由」は、私たちがコントロールできる外部のテーブルに、明確な構造として刻み込むべきなのです。