市民開発アプリ・AIエージェントに「消費期限」を設計せよ──作りっぱなしが組織を蝕む前にやること

Posted at 2026-04-01

🧭 この記事でわかること

ローコード・AIで作ったシステムに「消費期限」という概念を導入すべき理由
消費期限を設計段階で組み込む具体的なフレームワークと実装例
チームで運用する際の「期限管理ルール」の決め方と定例レビューの回し方

👤 対象読者

情シス・DX推進リーダー（市民開発の管理に悩んでいる方）
Power Platform / Copilot Studio / AIエージェントを現場で作っている方

✅ 結論（先に言い切る）

ローコード・AIで作ったものは「永久に使うもの」ではなく「期限付きの道具」である。設計段階で消費期限を決め、見直しトリガーを仕込んでおくことが、技術的負債を防ぐ最もコスパの良い方法だ。

ローコードやAIで作ったアプリ・エージェントは、従来のスクラッチ開発と比べて「手軽に作れる」反面、メンテナンスの責任が曖昧になりやすい。結果として、誰も管理しないシステムが組織内に増殖し、静かに負債化する。これを防ぐには、作る前に「いつまで使うか」を決めておくことが最も有効だ。

🔍 背景：なぜこの問題が起きるのか

現場で起きがちな状況

「とりあえずPower Appsで作った」「Copilot Studioでエージェント組んでみた」「ChatGPTのGPTsで業務ツール作った」──こうした個人発の小さなシステムは、今やどの組織にも存在する。

問題は、これらが成功すればするほど周囲に広がり、いつの間にかチームの業務基盤になることだ。しかし、作った本人は「ちょっとした便利ツール」のつもりで作っている。ドキュメントもない、引き継ぎもない、テストもない。

放置すると何が困るか

リスク	具体例
属人化	作った人が異動・退職すると、誰も修正できなくなる
データ不整合	接続先のAPIやデータソースが変更され、気づかず壊れる
セキュリティホール	古い認証方式のまま放置、共有リンクが全社公開のまま
運用コスト増	使われていないフローが裏で動き続け、APIコールやライセンスを消費

エンジニアは技術的負債の管理に33%もの時間を費やしているという調査がある。ローコード・AIツールの場合、作り手が非エンジニアであることも多く、この負債は可視化すらされないまま蓄積する。

🗺️ 全体像：「消費期限」設計フレームワーク

ポイントは「作った後に考える」のではなく、作る時点で期限を設計に組み込むこと。これにより、以下の3つが自動的に担保される。

見直しのタイミングが来る（忘れない仕組み）
廃止の意思決定がしやすくなる（「期限切れだから」で合意形成できる）
作りすぎの抑止力になる（期限管理コストを意識するようになる）

🔧 解決策：実装手順（再現できる形で）

Step 0. 前提（権限/環境/準備）

対象ツール: Power Apps / Power Automate / Copilot Studio / GPTs / 自作AIエージェント等
必要権限: SharePointリスト作成権限、Power Automateフロー作成権限
準備物: 管理台帳用のSharePointリスト（またはExcel Online）

Step 1. 管理台帳（SharePointリスト）を作る

まず、組織内のローコード・AI製システムを一元管理する台帳を作る。以下のカラム設計を推奨する。

{
  "リスト名": "LC_AI_System_Registry",
  "カラム": [
    { "名前": "SystemName",       "型": "1行テキスト",   "説明": "システム名" },
    { "名前": "Owner",            "型": "ユーザー",       "説明": "作成者・責任者" },
    { "名前": "Category",         "型": "選択肢",         "説明": "Power Apps / Power Automate / Copilot Studio / GPTs / その他" },
    { "名前": "CreatedDate",      "型": "日付",           "説明": "作成日" },
    { "名前": "ExpirationDate",   "型": "日付",           "説明": "消費期限" },
    { "名前": "ReviewCycle",      "型": "選択肢",         "説明": "3ヶ月 / 6ヶ月 / 12ヶ月" },
    { "名前": "ExpirationTrigger","型": "複数行テキスト", "説明": "条件ベースの期限トリガー（例：データ量1万件超過時）" },
    { "名前": "Status",           "型": "選択肢",         "説明": "運用中 / レビュー待ち / 廃止予定 / アーカイブ済" },
    { "名前": "NextAction",       "型": "複数行テキスト", "説明": "次のアクション" },
    { "名前": "DependencyCount",  "型": "数値",           "説明": "依存しているユーザー数・システム数" }
  ]
}

Step 2. 消費期限の決め方（判断基準）

消費期限は「なんとなく1年」ではなく、用途と依存度で決める。以下のマトリクスを参考にする。

# 消費期限マトリクス
短期（3ヶ月）:
  - 特定イベント向けツール（展示会受付、キャンペーン集計）
  - PoC・プロトタイプ
  - 個人利用の業務効率化ツール

中期（6ヶ月）:
  - チーム内で共有している業務アプリ
  - 定型レポートの自動化フロー
  - AIエージェント（プロンプトやモデルの陳腐化が早い）

長期（12ヶ月）:
  - 部門横断で利用しているシステム
  - 外部連携（API・データソース）を含むフロー
  - 承認ワークフローなど業務プロセスに組み込まれたもの

# 条件ベースのトリガー（時間に加えて設定）
条件トリガー例:
  - データ量が10,000件を超えたとき
  - 接続先APIのバージョンが更新されたとき
  - 利用者が当初の3倍を超えたとき
  - エラー率が月間5%を超えたとき
  - 作成者が異動・退職したとき

Step 3. 自動リマインドの仕組みを作る

Power Automateで「消費期限の30日前」にOwnerへ通知するフローを組む。

# Power Automate フロー定義（概要）
トリガー: スケジュール（毎日1回実行）
アクション:
  1. SharePointリスト「LC_AI_System_Registry」から
     Status = "運用中" のアイテムを取得
  2. フィルター条件:
     ExpirationDate <= today() + 30日
     AND ExpirationDate >= today()
  3. 該当アイテムごとに:
     - Ownerにメール通知（またはTeams通知）
       件名: "【要対応】{SystemName} の消費期限が近づいています"
       本文: |
         システム名: {SystemName}
         消費期限: {ExpirationDate}
         現在のステータス: {Status}
         
         以下のいずれかの対応をお願いします：
         ① 継続 → 期限を延長し、レビュー記録を残す
         ② 改修 → 要件を再定義し、作り直す
         ③ 廃止 → 利用者に通知の上、アーカイブする
     - Statusを「レビュー待ち」に更新

Step 4. 動作確認（テスト観点）

期待値: 消費期限30日前にOwnerへTeams通知が届き、Statusが「レビュー待ち」に変わること
失敗したときの切り分け:
- 通知が届かない → フローの接続（コネクタ認証）が切れていないか確認
- 該当アイテムが取得されない → フィルター条件の日付計算式を確認（addDays(utcNow(), 30) の書式）
- Statusが更新されない → SharePointリストの権限（フロー実行アカウントの編集権限）を確認

🔥 実務Tips（やると差がつく）

「消費期限」という言葉を社内で統一用語にする。「レビュー期限」「見直し日」だと形骸化しやすいが、「消費期限」は食品のアナロジーで直感的に伝わるため、非エンジニアの理解を得やすい
台帳登録をアプリ公開の前提条件にする。「台帳に登録しないと共有リンクを発行できない」というルールにすると、野良アプリの発生を根本から抑制できる
四半期に1回「棚卸し会」を開く。全システムのStatusを一覧で確認し、廃止・延長・改修の3択を15分で決める。意思決定の速さが仕組みの生命線
AIエージェント・GPTsは特に短めに設定する。プロンプトの前提知識やモデル性能は数ヶ月で大きく変わるため、6ヶ月以上の消費期限は原則つけない

⚠️ ハマりやすいポイントと回避方法

ハマり: 消費期限を設定しても、期限が来たときに「まだ使ってるから延長」が繰り返され、実質的に形骸化する
回避: 延長時に必ず「レビュー記録」を残すルールにする。最低限「①現在の利用者数 ②直近1ヶ月の利用回数 ③既知の問題点」の3項目を記録させる。数字を見れば廃止の判断がしやすくなる
ハマり: 台帳管理そのものが負担になり、誰も更新しなくなる
回避: 台帳のカラムは最小限（上記10項目程度）に留める。完璧な管理より「存在を知っている」状態を維持することが目的。更新頻度は四半期に1回で十分
ハマり: 作成者が「消費期限を短くされると自分の成果が否定される」と感じて抵抗する
回避: 消費期限は成果の否定ではなく、設計品質の証明であるというメッセージングが重要。「期限を決められる＝ゴールを定義できている」というポジティブな評価軸にする

🔐 運用・セキュリティの補足（管理者向け）

ガバナンス設計のポイント

Power Platform管理センターのEnvironmentポリシーと組み合わせて、未登録アプリの検出を自動化する。DLP（データ損失防止）ポリシーで許可コネクタを制限しつつ、台帳未登録のアプリを定期的にレポートする運用が理想
監査ログの活用: Microsoft 365コンプライアンスセンターの監査ログから、Power Appsの起動回数・最終利用日を取得できる。これを台帳のレビュー材料にする
共有リンクの棚卸し: SharePointの共有設定が「組織内の全員」になっているアプリは、消費期限に関わらず即時レビュー対象にする

事故りがちなパターン

退職者が作ったPower Automateフローが、退職後もサービスアカウントで動き続け、古いAPIキーで外部連携している
GPTsに社内のConfidential情報を含むプロンプトが埋め込まれたまま、リンクが社外に共有されている
PoCとして作ったアプリがそのまま本番運用に昇格し、エラーハンドリングが一切ない状態で数百人が利用している

📊 結果 / 効果

定量

野良アプリの可視化率: 0% → 90%以上（台帳登録の義務化により）
不要フローの削減: 四半期あたり平均15〜20件の廃止判断が可能に
障害対応時間の短縮: 台帳にOwnerと依存情報があるため、初動が平均30分→5分に

定性

「誰が作ったかわからないアプリ」がなくなり、情シスの心理的負担が大幅に軽減
市民開発者が「作って終わり」ではなく「運用まで含めて設計する」意識に変化
廃止のハードルが下がり、「壊すのが怖いから触れない」状態からの脱却

「やらなかった場合」との比較

観点	消費期限なし	消費期限あり
運用コスト	野良アプリが増殖し、管理不能に陥る	四半期ごとに棚卸しされ、常に把握可能
品質	壊れたまま放置されるシステムが発生	期限切れで強制レビューが入る
拡張性	個人依存のため引き継ぎ不可	台帳＋レビュー記録で属人化を防止
セキュリティ	古い認証・共有設定が残存	期限レビュー時にセキュリティチェックが入る

📝 学び・まとめ

学び1: ローコード・AIで作ったものは「永続するシステム」ではなく「消耗品」である。この前提を共有するだけで、チームの運用設計の質が変わる
学び2: 消費期限は「制約」ではなく「設計品質の指標」。期限を設定できるということは、そのシステムのゴールと前提条件が明確であることの証拠だ
学び3: 仕組みは軽く始める。台帳のカラムは10個以下、レビューは四半期に1回15分、判断は「継続・改修・廃止」の3択。完璧を目指すと仕組みそのものが負債になる

✅ 次のステップ（ここから行動）

SharePointリストで管理台帳（LC_AI_System_Registry）を作成する
自チームのローコード・AI製ツールを棚卸しして台帳に登録する（まず5件）
各システムに消費期限を設定する（迷ったら6ヶ月で仮置き）
Power Automateで消費期限30日前の自動通知フローを作る
四半期レビュー会を1回だけカレンダーに入れる（15分で十分）
「消費期限」の考え方をチームに共有する（この記事をSlackに貼るだけでもOK）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up