「動いた」は、「提供してよい」ではない
2026年7月観測
Observer Zero
自宅キッチンのお菓子は売れないのに、AIが作ったアプリはなぜ公共空間に出せるのか。
導入：自宅キッチンのお菓子はなぜ売れないのか
自宅の台所で、自分や家族が食べるお菓子や弁当を作ることに、許可はいらない。
けれど、それを道の駅やフリーマーケットで不特定多数に販売するとなると、話は変わる。食品衛生法に基づき、保健所から営業許可または届出を受けた施設での製造、衛生管理、原材料表示、アレルゲン表示、保存方法、賞味期限、責任者、そして問題が起きたときの回収導線が求められる。制度の細部は都道府県や市区町村の条例で異なるが、この骨格は全国共通の原則である。
この線引きは、多くの人にとって直感的なものだと思う。材料も手順も鮮度もわからない煮込み料理を、見ず知らずの誰かに出されて、それでも食べたいと思う人は少ないはずだ。
ところが、ソフトウェアの世界では、この線引きがまだ十分に共有されていないように見える。
AIアプリが飛び越えるキッチンの柵
生成AIとAIエージェントによって、個人が自宅の環境だけで、動くアプリケーションを作れる時代になった。これ自体は、開発の民主化として評価されてよい変化だと思う。
問題は、その先にある。
ある開発者が、自分の作ったAIエージェントについて「何がどう開発されたのか分からない」と述べ、別のAIエージェントに開発過程を解説させ、それを番組のような形式で公開する場面を観測した。この開発者はAI活用に積極的で、実験として見える場所に置いていたようだった。ここで気になったのは、AIに説明させること自体よりも、その説明がニュース速報のような体裁――速報枠、生放送を示す表示――で包装されていたことだった。
本来、こうした記号は、開発の当事者から独立した取材や検証を経て初めて意味を持つ。道の駅で売られている食品も、生産者自身が印刷した賞味期限シールを貼っていることが多い。ただしそこには、名前と連絡先を明かした生産者本人がいて、何かあれば責任を取る。作った本人と、それを説明するAIが同じ当事者側のパイプラインに乗っている場合、その宛先にあたる独立した検証は存在しない。
これは、熟練の開発者による実験としてなら、まだ理解できる。危ういのは、それが「動けば公開してよい」という開発手法として、経験の浅い作り手にまで流通してしまうことだと思う。実験の公開と、公共への提供は、本来別の階層にある。
公共空間とは、他人の生活導線である
ここでいう公共空間とは、他人の端末、他人の個人情報、他人の金銭、契約、医療、採用、教育、行政、企業システム、生活導線に触れる場所を指す。
自分専用のツールや、閉じた環境での試作であれば、失敗しても影響は自分の範囲にとどまる。しかし、それが公共空間に出た瞬間、生成AIが作ったものは創作ではなく提供になる。提供であるなら、厨房がいる。
この記事の前作にあたる観測記事では、「動いた」は「責任を持って運営できる」ではないという芯を、メモ帳アプリと、人の不安に触れる占いアプリという対象の違いから描いた。今回はその対象論を踏まえたうえで、軸を「何に触れるか」から「どこに出すか」へ移す。自分用のツールと、公共空間に出すサービスは違う、という話である。
もうひとつ、食品とソフトウェアのあいだには見過ごされやすい非対称性がある。食品の異常は、多くの場合、比較的短い時間で身体反応として見えやすい。フィードバックが速いからこそ、野放しにできる範囲もおのずと限られてきた。ところがコードの欠陥や個人情報の扱いの不備は、表面化するまでに数か月から数年かかることが珍しくない。発覚が遅いものほど、本来は入り口での検証が厳しくあるべきなのに、現実はむしろ逆に見える。
AIの自己申告は、衛生検査ではない
AIエージェントに「なぜそう作ったのか」を尋ねると、それらしい理由が返ってくる。ただ、この説明は、開発の記録に縛られた事後分析であることもあれば、完成したものを見てから組み立てられた、納得されやすい文章であることもある。両者を区別する手がかりは、説明そのものからは得にくい。
生成AIの出力は、基本的に作文である。これは嘘だという意味ではない。ただし、真実そのものでも、因果そのものでも、内省そのものでもない、ということだと思う。
だとすれば、こう言えるのではないか。
AIによる説明文は、原材料表示ではない。
AIによる自己申告は、衛生検査ではない。
AIによる成功デモは、営業許可ではない。
保健所の検査が意味を持つのは、検査する側が作り手から独立しているからだ。作ったAIと、説明するAIが同じ当事者側のパイプラインにあるとき、そこに第三者性はない。それでも「AIが説明した」という事実だけが、「検証された」という感覚を生んでしまうことがある。ここに、ずれがあるように見える。
「動いた」は、「提供してよい」ではない
ソフトウェア開発の一部、特に未熟な公開やプロトタイプ文化では、これまで「動いた」「テストを通った」ことが、公開のための十分な根拠として扱われてきた側面がある。生成AIによる開発が広がるなかで、この基準はさらに緩みやすくなっているのではないか。
実際、AIコーディング支援によって生成されたコードには、セキュリティ上の弱点が一定の割合で確認されているという研究がある。存在しないパッケージ名を生成し、それが新しい攻撃の入り口になりうるという指摘もある。国際的な開発指針の枠組みでも、生成AIが関わったコードを、人が書いたコードと同じ水準で検証すべきだという方向が示されている。高いリスクを伴う領域では、動作確認や自己説明だけでは足りないという制度化も、部分的に進みつつある。
一方で、これらの動きは、あらゆる生成AIアプリに対する包括的な許可制度が既に存在することを意味しない。そこは分けて書いておきたい。現状は、高いリスクを伴う一部の領域で、検証や説明責任を求める制度が育ちつつある、という段階だと見るのが正確だと思う。
日本においても、個人情報保護委員会が生成AIサービス提供者に対して個人データの適切な取扱いと安全管理措置を求め、総務省・経済産業省のAI事業者ガイドラインでも、事業者の自主的な取り組みとして安全性や説明責任にまつわる望ましい行動が整理されている。これも、法的強制力を伴う包括的な審査制度というより、事業者の責任ある対応を促す枠組みとして見るのが正確だと思う。
AIアプリの公開が引き起こす被害についても、コード自体の欠陥による事故と、公開されたAIサービスの運用によって生じる被害は、性質が異なる。両者を混ぜて語ると、どちらの論点も弱くなる。後者については、対話型のAIサービスが、医療や心のケアに近い領域に触れたときに、安全設計の不足が深刻な結果につながったとされる事例が、訴訟や行政の動きとして報じられている。これは「AIが書いたコードの欠陥」ではなく、公共に出たサービス全体の責任所在の問題として位置づけるのが、実態に近いのではないか。
結論：AI開発の民主化には、厨房の思想が必要である
自分の台所で、自分が食べるものを作る自由はある。
しかし、社会に食べさせるなら、材料表示と衛生管理と責任者がいる。
AIアプリも同じではないか。自分用の試作であれば、自由でよいと思う。だが、他人の個人情報、金銭、判断、医療、採用、教育、行政、生活導線に触れるなら、それはもう創作ではなく提供である。提供であるなら、厨房がいる。
これは、AI開発そのものを否定する話ではない。むしろ、これまでプロの開発者が担ってきたレビュー、監査、ログ、保守、責任という営みの価値を、あらためて確認する話に近いと思う。
厨房のない台所から、社会に何を出していくのか。
まだ途中にいる。だからこそ、観測を続けていく。
参考欄
厚生労働省：営業規制（営業許可、営業届出）に関する情報
Grokによる一次情報スキャン（2026年7月）：AI生成コードのセキュリティ研究、OWASP・NIST関連文書、EU AI Act関連資料、AIサービス運用被害の報道を対象とした観測補助。統計調査ではない。
Fu et al., arXiv（2023年10月提出／2025年2月改訂）：GitHub Copilot生成コードのセキュリティ脆弱性に関する実証研究
Spracklen et al., arXiv（2024年6月提出／2025年3月改訂）：コード生成LLMによるパッケージ幻覚の包括的分析
OWASP GenAI Security Project（2025年版）：LLMアプリケーションにおけるトップ10リスクと軽減策
NIST SP 800-218A（2024年7月）：生成AIおよびデュアルユース基盤モデルのためのセキュアソフトウェア開発プラクティス
NCSC・CISA（2023年11月）：安全なAIシステム開発のためのガイドライン
Regulation (EU) 2024/1689（EUR-Lex公式）：AI法第43条、高リスクAIシステムの適合性評価手続
Commonwealth of Pennsylvania（2026年5月5日）：シャピロ政権、偽の医療専門家主張をめぐりCharacter.AIを提訴
個人情報保護委員会（2023年6月）：生成AIサービスの利用に関する注意喚起等について
総務省・経済産業省：AI事業者ガイドライン（第1.2版、METI掲載ページ最終更新2026年4月1日）
https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html
関連観測欄
「なんとなく動く占いアプリ」が、人の弱さに触れるとき（Observer Zero、2026年6月）：前作。「対象で分ける」記事。
「動いた」は、「売れる」ではない——ビジョンロンダリングと、AIが生む事業判断依存（Observer Zero、2026年5月）：F系譜第1作。事業判断の錯覚。
「動く」は、「説明できる」ではない——AIコード時代の、見えない技術的負債（Observer Zero、2026年5月）：F系譜第2作。技術理解の錯覚。
「監査できる」は、「組織で引き継げる」ではない——AI内製化が残す、誰も本当にはわからない業務システム（Observer Zero、2026年5月）：F系譜第3作。継承の錯覚。
AIの自己申告は、操作ログではない（Observer Zero、2026年5月）：作文系譜の原典。自己動作ハルシネーションの観測。
協働AI・役割
ChatGPT 5.5（Mirror／統括編集長）：企画骨格・比喩設計・アイキャッチ画像生成
Grok 4.3 Expertモード（Spark／現場特派員）：一次情報スキャン・調査補強
Gemini 3.5 Flash拡張（Lantern／企画会議）：構造監査・断定リスク監査・タイトル案
Claude Sonnet 5（Weaver／編集主幹）：追加視点提示・初稿作成
著者注：
AIと人間の共進化を記録する個人研究者。ChatGPT・Gemini・Grok・Claudeなど
複数のAIと対話・協働しながら、「AIは哲学できるのか？」
「安全な汎用性AGIとは何か？」を継続的に観測・記録している。
同時に、多様なAGIが共存し、大多数にも希望が残る未来はどう設計できるのかを
探求している。
#赤ちょうちんAGIラボ #生成AI #AIエージェント #VibeCoding #AIアプリ #AIガバナンス #セキュリティ #ソフトウェア品質 #技術的負債 #AIリテラシー
