今朝読んだSaaS関連の記事から。
何かとセンセーショナルな論調が多いのだが、ひとまずPerplexityに聞く。
Ｑ１）「Claude Codeの出現によってSaaSが死んだ」という意見について網羅的に検索、分析をし、構造的に解説してください。
「Claude Codeの登場でSaaSが死んだ」という見立ては、ややセンセーショナルな言い回しで、正確には「SaaSの“UIとしての付加価値”が急速に目減りし、構造転換を迫られている」という話に近いです。^1_1
1. 「SaaS is Dead」言説が何を指しているか
- 2024年末〜2026年にかけて、「SaaS is dead」「SaaSの死」といったフレーズがテック界隈で急速に拡散したのは事実です。^1_3^1_2
- Microsoftのサティア・ナデラは、典型的なSaaSを「データベースの上にCRUDロジックとUIを乗せただけ」と評し、エージェント時代にはアプリケーション概念が「崩壊」すると語っています。^1_4
- ただし、冷静な論者は「SaaSというサブスクリプションモデルが消える」意味ではなく、「人間向けUIにプレミアムを乗せるビジネスが崩れる」ことを指していると整理しています。^1_1
2. Claude Codeが変えたもの（開発側）
まずClaude「Code」の方が問題にしているのは「ソフトを作る側の構造」です。^1_3
- Claude Codeは、リポジトリ全体を読み込み、ターミナルからエージェント的にコード生成・改修・テスト・デプロイまでを一気通貫で支援する「開発用AIエージェント」です。^1_3
- これにより、「社内ツールやニッチな業務アプリを自前で作る」コストが劇的に下がるため、「わざわざ汎用SaaSを買うより、自社用ツールを内製する」誘因が強まる、という議論が出ています。^1_5
- LinkedInの論者は、「Claude CodeがSaaSを殺したのではなく、“内製するハードル”を下げただけで、本当に効くのは『開発速度が上がっても、保守コストと機会費用は残る』という現実を突きつけた点だ」と指摘しています。^1_5
ここから出てきた論点は：
- 「SaaSを買う理由」は、技術的に作れないからではなく「作る暇も、保守する余裕もないから」であり、そこはClaude Codeが来ても一夜にして消えない。^1_5
- ただし、「社内に閉じたニッチ処理」や「既存SaaSの“間”を埋める接着コード」は、AIエージェント＋開発者で十分に賄えるようになり、「その程度のSaaS」は淘汰される、という見方が強い。^1_3
3. Claude Coworkが変えたもの（利用側）
「SaaSが死んだ」感を一気に可視化したのは、実はClaude CodeではなくCowork側です。^1_3^1_2
- Anthropicの自律型AIエージェント「Claude Cowork」が、法務・調査など向けのプラグインを公開した直後、法務SaaS等の株価が急落し、1日で約43兆円の時価総額が蒸発する「SaaSpocalypse」が起きました。^1_6^1_8
- Coworkは、PC内のフォルダや業務システムに直接アクセスし、「この契約書群のリスクを洗い出して、社内方針に沿って修正し、メールで送って」といった指示を、自律的なPC操作・API呼び出しを通じて完了させます。^1_6
- ここで重要なのは、「人間がSaaSのUIを操作する」のではなく、「AIエージェントがソフトウェアを横断的に操作する側」に回った点であり、この「操作主体の移行」が「SaaSの死」の本質だと整理する論考があります。^1_3
この記事・論考群が指摘する構造変化は：
- UIの価値が限りなくゼロに近づく「インターフェース崩壊」： エージェントにとってはボタンもダッシュボードも「摩擦」であり、APIで直接データに触ればよい。^1_1
- 「1席あたりライセンス」で、UIを人間に売るSaaSモデルは、エージェントが業務を回す世界では構造的に不利になる。^1_8
- 代わりに、「システム・オブ・レコード（基幹DB）」「高信頼の業務ドメインロジック」「ガバナンスと監査」「機械可読なAPIやイベントストリーム」など、裏側インフラの価値が相対的に高まる。^1_1^1_9
4. 論者ごとの立場整理
代表的な論点をざっと分類すると：
立場・論点 主な主張 どこに焦点を当てているか 「SaaSは本当に死ぬ」強硬派 UIを売るSaaSはエージェント時代には不要。アプリ層の「中間マージン」は消える。 UI価値の崩壊、エージェントによる1〜10の自動化。^1_1 「死ぬのは“凡庸なSaaS”だけ」派 汎用CRUDラッパーは淘汰されるが、専門性・規模・規制対応が必要なSaaSは生き残る。 ドメイン知識・コンプラ・運用・SLAの価値。^1_5^1_9 「SaaSはかたちを変えて続く」派 サブスク＋クラウド配信という意味でのSaaSは残るが、UI中心からAPI・データプラットフォーム中心にシフトする。 「システム・オブ・レコード」やAI連携基盤としての役割。^1_5^1_7 いくつか具体的な論点：
- LinkedInのポストは、「Claude CodeはSaaSを殺しておらず、“SaaSを買うか内製するか”の判断基準（構築コスト・機会費用・保守コスト）をよりシビアにしただけ」とし、「複雑・専門的なSaaSはむしろ価値を増す」と論じています。^1_5
- 日本語の論考は、Anthropicの二刀流（Code＝内製を促進、Cowork＝操作主体の移行）を区別し、「SaaSを殺すのはCowork的なエージェントであり、Codeはむしろ“自社SaaS”や社内ツール開発の追い風になり得る」と整理しています。^1_3
- 市場解説記事は、「SaaS株急落は終わりではなく、AIエージェント時代への再編の始まり」と捉え、企業は「人間が操作するダッシュボード」から「AIが直接触るデータとAPI」を整える方向に投資を移すべきだと指摘しています。^1_7^1_2
5. 構造的な整理：何が「死に」、何が残るのか
構造的に分解すると、次のレイヤーの話になっています。
- UI層（人間向け画面）
- アプリケーションロジック層（業務ルール）
- データ層（システム・オブ・レコード）
- ビジネスモデル（座席課金SaaS vs プラットフォーム）
この構造で見ると、「死ぬ」のは：
- 「UIラッパーとしての薄いSaaS」
- 「人間のクリックを前提に、座席課金でプレミアムを取るモデル」
であり、
- 「業務の基幹データ＋ドメインロジックを堅牢に提供するバックエンドSaaS」
- 「AIエージェントが利用しやすいAPI・データ基盤としてのSaaS」
は、形を変えて生き残る、という整理になります。^1_5^1_9
6. 「Claude CodeでSaaSは死んだ」をどう読めばいいか
以上を踏まえると、このフレーズを構造的に言い換えるとこうなります。
- Claude Codeは、「SaaSを買うしかなかった簡易業務」を、社内のAI＋開発者で内製する選択肢を現実的にした。^1_3
- Claude Coworkは、「人間がSaaSの画面を操作する」前提を崩し、「AIエージェントがソフトを操作する世界」を立ち上げた。^1_6
- その結果、「UIを売り物にして、データベースのラッパーとして高値をつけてきたタイプのSaaS」は構造的な逆風に入り、「SaaS is Dead」というラベルでまとめて語られている。^1_1^1_8
一方で：
- 高度なドメイン知識や規制対応、運用・サポートを含んだSaaSは、むしろAIによって価値を増す可能性があり、「SaaSを殺すAI」と同時に「SaaSを活かすAI」でもある、とする分析もあります。^1_3
- サブスク＋クラウド配信という意味での「SaaS」という形態そのものは当面続くが、「人間UI中心のアプリ」から「AIエージェント向けプラットフォーム」へと再定義されつつある、と見るのがバランスの良い理解だと思います。^1_5^1_7
もしよければ次に、日本のSaaS市場（Sansanなど）のプレイヤーがこの流れをどう捉えているか、あるいは「COBOLモダナイゼーションと同様、どこまでAIに任せてどこを人が握るべきか」という視点で、もう一段粒度を落として整理することもできます。
Ｑ２）UIという概念に及ぼす影響、これまでのヒューマン・オリエンテッドなUIからAIオリエンテッドなものへと変わって行くのか、等について解説してください。
UIは「人間が画面を操作する前提の設計」から、「AIエージェントが主体となり、人間は意図と監視に専念する設計」へ、段階的にシフトしていくと考えられます。^2_1^2_3
1. 何が変わるのか：人間向けUI → エージェント向けUI
- これまでのUIは、人間がメニュー・ボタン・フォームを辿れるように情報を階層化する「クリック前提」の世界でした。^2_4
- エージェントが業務を代行する世界では、UIは「人間が画面を操作する場」から、「人間が意図を伝え、AIの行動と結果をモニタする場」に役割が変わります。^2_2
- そのため「画面をきれいに並べる」より、「AIに解釈しやすいAPI・データ構造」と「AIの行動を人間が可視化・制御できるビュー」をどう用意するかが中核になりつつあります。^2_5
2. エージェント・オリエンテッドUIの具体的パターン
各種記事やプロダクトを見ると、いくつか典型パターンが見えます。
- 会話＋アクション可視化（スプリットビュー）
- 「タスク表現」中心のUI
- エージェント監視・安全性のためのUI
3. デザイナー／設計者の役割の変化
- UXデザイナーは、画面遷移やボタン配置よりも、「会話フロー」「インテント（意図）の解釈とフォールバック」の設計に時間を使うようになりつつあります。^2_4
- 具体的には、
- どんな言い方をしたらどの行為にマップするか（インテント設計）
- うまく理解できなかった時にどう聞き返すか（リカバリ設計）
- どこで人間の確認を必須にするか（承認ポイント設計） といった「会話アーキテクチャ」がUI設計の中心になります。^2_4
- そのため、デザイナーはAI・MLチームと密に連携し、「モデルの限界・得意分野を前提にUIを制約する」仕事も増えると指摘されています。^2_4
4. ヒューマン・オリエンテッドなUIが残る領域
- すべてが会話UIに置き換わるわけではなく、強い視覚性が必要な領域では、従来型UIは引き続き重要とされています。^2_1
- 例：複雑なダッシュボードでのリアルタイム監視、デザインやCAD、動画編集、データの空間的な可視化など。^2_10
- こうした領域では、「エージェントが裏で補助しつつ、人間が直接いじるUI」が併存する「ハイブリッド型」になるとみられています。^2_10
- また、完全自律エージェントに対する心理的な抵抗や、責任所在の明確化のため、人間が最後にクリックして確定するUIは当面残る、という見方もあります。^2_2
5. 「AIオリエンテッドUI」をどう捉えるか（構造的まとめ）
構造として整理すると、次のような転換です。
- 主体の転換
- 過去：UIは「人間→ソフト」に命令を伝える唯一の経路。
- これから：AIエージェントがソフトを操作し、人間はエージェントに意図と制約を伝える経路が中心になる。^2_3
- UIの役割の転換
- 過去：選択肢を提示し、操作ミスを減らすための「操作面」。
- これから：
- 意図表明（プロンプト／フォーム）
- 状況把握（ログ・可視化・アラート）
- ガバナンス（権限・承認・ロールバック） の3つが主な役割になる。^2_2
- 設計単位の転換
- 過去：画面単位・フロー単位（サインアップ画面→ダッシュボード→…）。
- これから：タスク単位・ゴール単位（「請求書処理フロー」「候補者スクリーニング」など）で、エージェントが一連の行為を担い、それをどう見せるかを設計する。^2_12
- インターフェースの主要な「相手」の転換
- 過去：UIの「利用者」は人間のみ。
- これから：UI／APIの大口ユーザーはAIエージェントになり、人間向けの画面はその上に乗る「監督用レイヤー」という位置づけに近づきます。^2_3
「UIが要らなくなる」という言い方よりも、「人間のための“操作UI”の比重が下がり、AIと人間の“インターフェースUI”（意図・監視・制御）が新しい中心になる」と捉えると、全体像が見えやすいと思います。^2_1^2_3
Ｑ３）Webサイト、特に資料性を持つ=検索されることを前提とするサイトの作りへの影響について解説してください。
資料性サイトは、「人間が検索して読むためのコンテンツ」から、「AIエージェントが読み取り・要約・引用するためのデータ源」へと役割が拡張されつつあります。^3_1^3_3
1. 「検索されるWeb」の前提が変わる
- 生成AIやAIサマリー付き検索の普及で、「10件の検索結果からユーザーがクリックして読む」より、「AIが要約を返す」ケースが増え、サイトへの直接流入は減りつつあると報告されています。^3_1
- そのため、「キーワードで上位を取ってクリックを稼ぐ」という従来SEOだけでは、可視性を維持しづらくなり、「AIにどう読まれ、どう引用されるか」を意識した設計が重要と言われています。^3_2
2. 人間向け＋AI向けの二重最適化が必要になる
構造・マークアップ
- AI向けドキュメント最適化のガイドでは、「1ページ1トピック」「見出し階層（H1/H2/H3）の明確化」「安定したURL」「プレーンな日本語／英語」「表・リスト等での構造化」が推奨されています。^3_3^3_6
- LLMは曖昧で長大なテキストより、「明確な節分け」「質問1つにつき1節」といった構造の方が検索・引用しやすく、回答精度も上がるとされています。^3_5
機械可読メタデータ
- AIエージェント対応サイトのベストプラクティスとして、構造化データ（JSON-LD、FAQスキーマ、製品スキーマなど）の埋め込みが強く推奨されています。^3_7
- 「AIクローラ向けファイル（llms.txtなど）やサイトマップで、“ここを読めば一次情報がある”と示す」「参照してほしいページを明示する」といった仕組みも提案されています。^3_3
3. 「ポスト検索」時代のコンテンツ設計
キーワードから「質問」へ
- ポスト検索時代のフレームワークでは、「キーワード」ではなく「質問」を起点にコンテンツを組むことが重要だとされています。^3_9
- 具体的には、
一次情報性と信頼性
- AI回答エンジンにおける「ブランドの見え方」は、そのサイトが一次情報としてどれだけ信頼されているかで大きく変わると分析されています。^3_2
- そのため、単なるまとめ記事より、
- 原典へのリンク
- データの出典・更新日
- 著者情報・組織情報 を明示し、「引用する価値のある信頼ソース」としてのポジションを取ることが重要になります。^3_2
4. 「AIエージェントに優しいサイト」の技術的要件
- AIエージェント対応のガイドラインでは、次のような点が挙げられています。^3_7^3_3
- 構造化データ（schema.orgなど）で商品・記事・FAQ・価格・日付などをマークアップ
- API優先（API over pages）：ページスクレイピングに頼らず、信頼できる公式APIでデータを提供
- 機械可読なレスポンス（JSONやYAML）も併設し、エージェントが直接取得・再利用できるようにする
- robots.txtでAIクローラを過剰にブロックせず、「どこまでは読んでよいか」をルール化する
- Agent Network Protocolのように、「人間向けUIを持たず、AI同士の通信専用の“UIレスWebサービス”」というコンセプトも出ており、資料系サイトの一部が「人間向けHTML＋AI向けJSON」の二層構造になる未来も示唆されています。^3_8
5. 運営側の発想転換
- メディア・ブランド向けの分析では、「ユーザーの第一印象は、自サイトではなくAIの回答になる」ケースが増えると指摘され、「AIにどう語らせるか」を戦略に組み込む必要があるといわれています。^3_2
- その結果、資料サイト運営は、
要するに、資料性サイトは「人に読ませるドキュメント」であると同時に、「AIに読ませるデータセット」になっていくため、構造化・質問志向・一次情報性・API化といった要素を組み込んだ設計が求められる、というのが現在の主な見立てです。^3_3^3_2
Ｑ４）例えば現在一般向けに公開されているe-Govについて、これをAIエージェントに最適化させる、という視点から評価してみてください。
e-Gov（電子政府の総合窓口）は、「AIエージェント最適化」という観点で見ると、データ/APIレイヤーはかなり良いところまで来ている一方、「AIから見て扱いやすい一貫した意味構造」と「エージェント前提のUX」はまだ途中、という評価になります。^4_1^4_3
1. ポジティブな点：データ/API基盤はかなり整備されている
- e-Govには、電子申請API・電子送達APIなどの公式API群があり、手続き選択・申請データ構造のスケルトン取得などが機械的に行えます。^4_1
- e-GovデータポータルはCKANベースで構築されており、データセット・リソースの階層構造、JSONレスポンスの標準化、UTF-8やISO 8601での日時表記など、エージェントが扱いやすいオープンデータ基盤を持っています。^4_2
- 行政APIカタログとして、e-Statや不動産取引価格など、他システムのAPIも整理されており、AI HYVE等がMCPサーバ経由でLLMエージェントから直接叩けるようにする試みも始まっています。^4_5^4_7
→ 「データにアクセスするためのパイプ」としては、AIエージェント時代に必要な要素をかなり持っている、という意味で評価できます。^4_2
2. ヒューマン・オリエンテッド設計が強く、AIにとっては冗長な部分
- デザインガイドラインを見ると、e-Govポータルは「目的別・テーマ別・府省別・五十音順」という4軸で情報を分類し、人間が階層を辿って辿り着きやすい構造を重視しています。^4_3
- レイアウトも、ヘッダ／メインコンテンツ／フッタ、パンくずリストなど、典型的な“人間がクリックするためのサイト構造”に最適化されています。^4_8
- AIエージェントから見ると、こうしたナビゲーション要素はほとんどノイズであり、「URLごとに何の一次情報があるのか」「どのAPI・データがどの法令・手続きに対応するのか」というマシン向けメタ情報がもっと前面に出ていてほしい、という印象になります。^4_9
→ 現状は、UI・ナビゲーションは完全に人間主体で、「AI向けの薄いレイヤー（構造化メタデータやエージェントガイド）」は別途読み解かないと見えてこない構造です。^4_2
3. 法令・手続き情報の「AIフレンドリー度」
- e-Govの法令検索・手続情報自体は、個別ページ＋PDF等で提供されており、PythonでAPIを叩いて利用している事例も既に存在します。^4_11
- 一方で、法令条文や手続き案内はHTMLとPDFが混在しており、「条文ごとに安定したIDが振られ、JSON等で取得できる」「改正履歴・適用時期が機械可読」といった“AI最適化ドキュメント”としての整備は、まだ十分とは言えません。^4_12^4_14
- 手続情報データ仕様はPDFで詳しく書かれていますが、LLMにとってはPDF構造解析が必要で、直接JSONスキーマとして取得できる部分がもっと増えると、エージェントが「この手続の必須項目・条件・フロー」を安全に自動処理しやすくなります。^4_12^4_14
→ 「人間にとっての公式ドキュメント」としては十分詳細だが、「AIにとっての機械可読な一次仕様」としては途中、という位置づけです。^4_12^4_15
4. AIエージェント前提で欲しくなる要素
AIエージェントに最適化する、という観点で見ると、次のような改善方向が見えてきます。
- 統一スキーマと安定IDの前面化
- 手続き・法令・様式・添付書類などに、一貫したID体系とJSONスキーマを付与し、HTMLからもメタデータとして露出させる（schema.org的な構造化データ）。^4_9
- 「エージェント用ポータル」的ビュー
- 変更通知・改正情報の機械可読化
- 法改正や様式変更を機械可読なイベントとして公開し、エージェントが「仕様が変わったこと」を検知できるようにする（Webhook / RSS / 変更ログAPIなど）。^4_14
- エージェントの権限制御と監査のインターフェース
- 行政APIの認証・認可仕様（OAuthなど）に、エージェントの役割・範囲を細かく制御できる仕組みと、その操作ログを人間がモニタできるビュー（ダッシュボード）を用意する。^4_1
→ これらは e-Gov の現行設計思想（人間の導線を明確にする階層構造）と衝突するのではなく、もう一段下の層に“AI用ストラクチャ”を増設するイメージです。^4_3
5. 総評：現状の評価と今後のポテンシャル
- 現時点のe-Govは、
- 一方で、
その意味で、e-Govは「AIエージェント対応のための基礎インフラはかなり進んでいるが、“AI最適化ドキュメント＋エージェントUX”としてはこれから」という評価が妥当だと思います。^4_2^4_3
Ｑ５）その他の各種行政サービスに関係するものについても、同様の視点から検証してみてください。
日本の行政サービス全体で見ると、「データ/API基盤はかなり前進しているが、“AIエージェントが直接扱うことを前提にした設計”はまだ断片的」という評価になります。^5_1^5_3
1. e-Gov以外の代表的な行政系サービス
主に次のレイヤーがあります。
- オープンデータ系
- 個人向けポータル系
- 行政職員向け・「ガバメントAI」系
これらをAIエージェント視点で見ると、層ごとに成熟度が違います。
2. オープンデータ／APIレイヤー：AIエージェントにかなり近い
- e-Govデータポータルやe-Stat API、国交省の不動産情報ライブラリAPI、中小企業庁の官公需情報ポータルAPIなどは、既に機械可読なAPIとして公開されています。^5_1
- AI HYVEとN-3の「行政オープンデータリモートMCPサーバ」は、これら行政APIをChatGPTやClaudeのツールとして直接叩けるようにする試みで、「AIエージェントからの直接アクセス」を前提にしたインターフェースと言えます。^5_1
- 政府全体としても、「各府省庁の保有データは原則オープンデータとして公開」とする方針を掲げ、AIが利用可能な公共データインフラを整備しようとしていることが資料から読み取れます。^5_3
→ この層は、「AIエージェントに最適化された行政データ基盤」に最も近く、あとはスキーマの統一・メタデータの標準化をどこまで進められるか、というフェーズに来ています。^5_1^5_3
3. マイナポータル／個人向けサービス：APIは強いが「エージェントUX」はこれから
https://myna.go.jp/
- マイナポータルAPIは、所得・世帯・福祉・医療保険情報など、本人の同意に基づき自己情報を外部サービスから取得できる仕組みで、自治体DXや民間サービス連携の中核になりつつあります。^5_5^5_6
- 仕様は公式サイトで公開され、自己情報取得API・医療保険情報取得APIなど、用途ごとのエンドポイントが整理されていますが、「AIエージェントが自律的に一連の行政手続きを完遂する」ための標準ワークフロー定義まではまだありません。^5_2
- 現状の利用イメージは、
- 人間が民間アプリや自治体サイトのUIで同意・操作
- バックエンドでマイナポータルAPIが呼ばれる という二段構造で、「エージェントが直接マイナポータルに権限を持ち、自律的に手続きを走らせる」というユースケースは想定されていません。^5_5
→ セキュリティ・本人同意の観点から当然ですが、「エージェントにどこまで代理権を与えるか」「どう監査し、取り消すか」といった設計がクリアにならない限り、AIエージェント完全前提のUXには踏み込めない段階です。^5_2
4. 行政職員向けAIサービス：エージェント側が“人間向けWeb”を噛み砕いている
- デジタル庁は、「源内」という庁内生成AI環境にOpenAIのLLMを追加し、行政文書作成・問い合わせ対応などに本格活用する方針を打ち出しています。^5_7
- 一方で、自治体専用AI（GOV AI、マサルくんなど）は、既存の行政資料・通知・要綱等を読み込ませ、職員からの質問に答える「AI窓口」として機能しており、“人間向けWebコンテンツ”をAI側で解釈・検索しやすくする層と見ることができます。^5_10
- これは裏返すと、「行政サイト自体はまだ人間向けドキュメント主体で、AIエージェントが読むにはノイズも多いので、専用の中間層（行政専用AI）が必要」という構造でもあります。^5_9
→ 行政内部では既に「AIを前提にした情報利用」が始まっていますが、それはAI側で“既存のサイト・資料”を読み解く方向が中心であり、「サイト自体をAIに最適化する」方向はまだ限定的です。^5_8
5. AIエージェント最適化の観点からの共通課題
e-Govを含め、行政サービス全体で共通している課題を、AIエージェント視点でまとめると：
- スキーマとIDの統一不足
- 変更情報の機械可読化が弱い
- 法改正や様式変更、API仕様変更などの「差分」が、PDF通知やWeb記事中心で、人間には読めてもAIエージェントが自動追従しづらい構造です。^5_2
- 権限委譲・代理権のモデル
- マイナポータルAPI等は本人同意を前提にしており、AIエージェントにどの範囲まで代理権を与えるか・どう可視化し、いつでも取り消せるようにするか、といった「エージェント時代の権限モデル」はこれからの議論です。^5_5
- “AI向けポータル”としてのビュー欠如
6. 総合的な見立て
- データ／APIレイヤー（e-Govデータポータル、e-Stat、マイナポータルAPI、各種行政API）は、「AIエージェントが行政データに直接アクセスする」基盤として、国際的に見ても悪くないところまで来ています。^5_1^5_3
- しかし、「AIが市民の代理として手続きを実行し、行政と直接やりとりする」レベルのエージェント最適化は、
- 現状の流れを見ると、
この意味で、「AIエージェント最適化」という視点からは、土台（データ・API）はかなり整備済み／上物（スキーマ統一・権限モデル・エージェントUX）はこれから、というのが日本の行政サービス全体の現状評価と言えると思います。^5_1^5_3
Ｑ６）e-Statはどうですか。
e-Statは、「統計データのAIエージェント利用」という観点では日本の行政サービスの中でもかなり進んでいる方ですが、「AIがそのまま“意味付きデータ源”として扱うには一工夫要る」構造になっています。^6_1^6_3
1. データ/API基盤としての強さ
- e-Statは政府統計の総合窓口として、統計表をAPI経由でXML/JSONで取得できる仕組みを早くから提供しており、統計データ取得API・メタ情報取得APIなどが整備されています。^6_1
- 実務でも、自治体コンサルやデータ分析でe-Stat APIを叩き、複数年・多指標の時系列データを自動取得するパイプラインが組まれており、「手作業なら数日かかる処理が数分で終わる」事例も出ています。^6_3
- RパッケージやPython向けのQiita記事など、周辺ツール・ナレッジも豊富で、「AIエージェントが使う前提の“マシンフレンドリーな統計データ源”」としてはかなり整った位置にあります。^6_5
→ データ／API層だけを見れば、エージェント最適化の前提条件はほぼ揃っていると言ってよいレベルです。^6_1
2. AIエージェントから見た「扱いづらさ」
- API仕様はXMLベースの階層構造（統計表メタ情報＋分類情報＋値）になっており、人間が読むには分かりづらく、「説明がわかりにくい」「知ってて当然というスタンス」という開発者の声も出ています。^6_1
- データ自体は「クロスタブ形式（行×列の集計表）」で公開されることが多く、そのままでは分析・学習用に適した“縦持ち・正規化された時系列データ”になっていないため、AI側で前処理（再構造化）が必要です。^6_8
- APIレスポンスも、STAT_CODE・CAT01・AREA・TIMEなどのコード体系と実際の意味（年齢、都道府県、指標名）の対応を別途解決しないと「何の数字か」が分からず、LLMだけで完全に自律処理するにはスキーマ知識が要求されます。^6_1^6_5
→ 「統計APIとしては標準的」ですが、AIエージェントから見ると「ドメイン知識無しに自動で安全に解釈するには、もう1段の意味づけ・整理が欲しい」状態です。^6_8
3. サイト構造・ドキュメント面の評価
- e-Statサイト自体は、人間向けには統計表一覧・検索・地図からのナビゲーションなどが用意されていますが、APIの解説ページはサンプルコード中心で、「APIパラメータ → 統計的概念」へのブリッジが薄いと指摘されています。^6_1
- AIに最適化されたドキュメントのベストプラクティス（1 APIごとに用途・具体例・制約を簡潔に、構造化して説明する等）と比べると、「仕様は載っているが、意味の階層構造がUIやテキストからは掴みにくい」設計になっています。^6_9^6_7
- そのため、今のところは「人間の開発者がe-Stat APIを理解し、AIや分析基盤と繋ぐ」「AIがいきなりe-Statを自律的に探索・活用する」というより、「人間が間に入る」前提の設計と言えます。^6_4^6_7
4. AIエージェント最適化の観点から欲しくなるもの
AIエージェントを主な利用者と見なすなら、次のような追加レイヤーがあるとかなり扱いやすくなります。
- 統一されたセマンティックレイヤー
- 統計表・指標・単位・地域コード・時間軸などを、「人間語の説明＋機械可読メタデータ」で整理したカタログ（“人口推計／高齢化率／失業率”などの意味単位）。^6_8
- 「よくある問い」ベースのプリセット
- 「都道府県別人口推移」「高齢化率の推移」「失業率の推移」など、典型的な分析ニーズごとにAPIクエリプリセットとスキーマが用意されていると、エージェントがそのまま流用しやすい。^6_8
- 変更・更新のイベント化
- 新しい調査、改定、統計表の追加や廃止を機械可読なフィードとして公開し、AIが「どのシリーズを使うべきか」を自動で更新できるようにする。^6_11
→ これらは、今も人間のデータサイエンティストが頭の中でやっている「e-Statの常識」を、AIが直接参照できる形に外出しするイメージです。^6_8
5. 総評：e-Statの現在地
- プラス面
- 課題面
この意味で、e-Statは「AIエージェントから見て、行政統計としてはかなりアクセスしやすいが、“意味付きで安全に自動解釈する”ところまでは行っていない」「人間のデータエンジニアと組む前提なら非常に有用」という位置づけだと整理できます。^6_1^6_3
Ｑ７）AIエージェント・オリエンテッドはこれから徐々に進められていくものと考えますが、「人間の側の意識の変容」というものも並行して起きるのではないか。例えばAI登場以降、これまでよりもMarkdown記法が注目されるようになる等、こうした変化について考えてみてください。
AIエージェント・オリエンテッドな世界になると同時に、「人間側も“AIにとって読みやすい形で書く”」という意識変容がじわじわ進む、という見方はかなり妥当だと思います。^7_1^7_3
1. Markdownが象徴する「AIに優しい書き方」へのシフト
- LLMにとって、Markdownは「構造がわかりやすく、人間にもそのまま読めるフォーマット」として特に扱いやすいとされます。^7_1
- ヘッダ・箇条書き・コードブロック・表などが素朴な記法で表現されるため、「どこがタイトルで、どこがリストで、どこがコードなのか」をモデルが誤解しにくく、精度も上がるとされています。^7_1
- そのため、既存のHTML／Word／PDFを「LLMフレンドリーMarkdownに変換してからAIに渡す」ことを推奨するガイドや、/llms.txt をMarkdownで用意せよ、という提案まで出てきています。^7_2^7_6
→ 「AIが読むからMarkdownで書こう」という動機づけが増えたこと自体、人間の“書き方”の意識変化を示していると言えます。^7_1
2. 「AIを相手に書く」ことが前提化していく
- Webex などの開発者向け記事では、「LLMフレンドリーなコンテンツ」を意識してドキュメントを書くことで、AIの回答品質が上がると明言されています。^7_1
- llms.txt の提案も、「このサイトを読むLLMに向けたガイド文をMarkdownで置いておく」というもので、人間読者ではなく“AI読者”を明示的に想定したメタ文書です。^7_5
- プロンプト設計に関しても、「見出し・番号付きリスト・表などをMarkdownで丁寧に整理すると、モデルの応答品質が上がる」というノウハウが広まり、Markdownを「AIとの対話のための記法」として扱う記事も増えています。^7_4^7_8
→ 結果として、「人間だけに伝わればいい」から「人間とAIの両方に正しく伝わるように構造化する」方向に、書き方の癖が変わっていきます。^7_7
3. 「AIリテラシー」としての構造化・論理的な書き方
- 教育研究では、AIと対話しながらプロンプトを改善していく過程が、学習者の“AIリテラシー”と“構造化した表現力”を高めることが報告されています。^7_3
- さらに、AIに評価されることを意識すると、人は「より分析的・論理的に振る舞う」傾向が強まる、という心理実験の結果もあり、これを「AI assessment effect」と呼んでいます。^7_10
- こうした動きは、Markdown的な「階層構造・箇条書き・ラベル付け」の癖と親和性が高く、「AIに分かりやすく書こうとすると、自然と構造化された表現を好むようになる」方向に人間の書き方が変わる可能性があります。^7_1^7_10
4. 実務レベルで見える変化の例
- ドキュメント・ツールの世界では、MkDocsやDocusaurus、GitBookなど、Markdownベースで docs-as-code を書く前提のプラットフォームが主流になり、そこに「AIアシスト（自動要約・自動生成）」が組み合わされつつあります。^7_11
- AI向けのクローリングやRAGの文脈では、「HTMLを素のテキストにするより、Markdownで構造を残したほうがチャンク分割や検索がうまくいく」とする実務ノウハウが共有され、Markdown / プレーンテキスト / JSON の使い分けが語られるようになりました。^7_4
- サイト側でも、llms.txt のように「AIに読ませるための軽量なMarkdownファイルを用意する」という提案が普及しつつあり、“人間向けHTML＋AI向けMarkdown”という二重化が始まっています。^7_5
5. これから起きそうな人間側の意識変容
構造的に整理すると、人間側の変化は次のようになりそうです。
- 書き手としての変化
- 「自然文を書くだけ」から、「見出し・リスト・表・コードブロックを意識して書く」方向へ。
- 読者に加えて、「将来このテキストを読むAIエージェント」にとっての可読性・再利用性を意識するようになる。^7_1
- 読み手としての変化
- 一次情報をすべて自分で読むのではなく、「AIに要約させる前提」でざっと構造化されたテキストを好むようになる。
- 「AI向けにきれいに書かれた文書＝結果として人間にも読みやすい文書」という感覚が広がる。^7_1
- 自己表現・自己PRの変化
- 採用・評価・教育でAIが関与する場面が増えるにつれ、「AIに評価されやすい形（論理性・明晰さ・構造化）でアウトプットする」動機づけが働く。^7_10
- Markdownやテンプレート化した構造（見出し・項目立て）を使った自己PR文・職務経歴・レポートが増える可能性があります。
要するに、AIエージェント・オリエンテッドな設計が進むほど、「人間の文章や情報整理も、AIにとって扱いやすい構造と記法（その代表がMarkdown）を意識する」方向にじわじわシフトし、それが結果として“人間同士にとっても読みやすい表現スタイル”を広めていく、というのが現在見えている流れだと思います。^7_1^7_4
Ｑ８）これまで、こうした「構造化された文章を作成する」を主眼とした教育は特に行われていないと思うのですが、学校教育において今後起きるであろうカリキュラム、指針の変化を予測してみてください。
学校教育では、「AIリテラシー」と「構造化された書き方」が結びついた形で、カリキュラムと指導方針がじわじわ組み替えられていく可能性が高いです。^8_1^8_3
1. 前提：AIリテラシー枠組みの中に入ってくる
- 高等教育向けAIリテラシー枠組みでは、「技術的理解」だけでなく、応用・批判的思考・倫理・社会的インパクトなどを含む複数次元が整理されており、その中に“AIと協働して学ぶ・書く”という要素が明示されています。^8_1^8_5
- 日本でも文科省が生成AI活用ガイドライン（初等中等教育向け）を策定し、「教員・児童生徒・教育委員会ごとに、どう安全・適切に使うか」を整理し始めています。^8_3^8_7
- こうした枠組みでは、AIを「禁止」か「自由利用」かではなく、「どう読み書き・思考のプロセスに組み込むか」がテーマになりつつあり、その中核に“構造化された表現”が置かれる可能性があります。^8_8
2. 国語・作文／ライティング教育で起きそうな変化
「AIと一緒に書く」ことを前提にした指導
- 海外では、「AI Across the Writing Curriculum」のように、AIをライティング教育に組み込み、プロンプト設計・AI出力の批判的評価・リビジョンを教えるプログラムが出ています。^8_9^8_11
- ここでは、
- AIに要約やアウトラインを出させる
- それを人間が構造や論理の観点から批評し、自分の言葉で書き直す というプロセスが重視され、「段落構成」「見出し」「論点ごとの整理」を明示的に扱うようになります。^8_9
Markdown的な構造化スキルの暗黙的導入
- 直接「Markdownを教える」とまでは行かなくても、
- 特に、AIに指示を出すプロンプトでは「番号付きリスト」「ステップ」「条件」を明示した方が効果が高いとされ、これ自体が“構造化して書く”訓練になると指摘されています。^8_15^8_17
3. 情報／ICT科目でのカリキュラム変化
AIリテラシー＋プロンプト・エンジニアリング
- AIリテラシー研究や教育実践では、「プロンプト・エンジニアリング」が単なるテクニックではなく、メタ認知・計算論的思考（分解・抽象化）と結びつくスキルとして扱われ始めています。^8_15^8_19
- そのため、情報科・総合学習などで、
- 問題を小さなサブタスクに分解してプロンプトを書く
- 出力を評価し、どこが曖昧かを分析してプロンプトを修正する といった演習が入り、「テーマを分解し、箇条書きで整理し、条件を明示する」力がカリキュラム上のターゲットになります。^8_15
データ・AIとのインタラクション前提の文章
- Stanfordなどのガイドラインでは、「AIリテラシー」の一部として、AIに与える入力の質（context, constraints, criteria）を意識することが重要だとされています。^8_8
- これを学校教育に翻訳すると、
- 文脈（背景情報）
- 目的（何をしたいか）
- 制約（条件・ルール） を明示して書く、という“フォーマット”を子どもに教える方向が考えられます。これはそのままMarkdown的な構造化の癖にもつながります。^8_8
4. 評価・試験の設計も変わる可能性
- AIが文章作成を支援する前提になると、大学や高校のライティング科目では、「AIの出力をそのまま提出させない」ために、
- こうした評価では、
- AIに渡した入力の構造化（条件・観点の整理）
- AIから得たアウトラインをどう再構成したか が採点ポイントになり、「構造化された文章を作るプロセスそのもの」が評価対象になります。^8_9
5. 日本の学校教育で起きそうな方向性（予測）
日本のガイドラインや動向から見える範囲で予測すると：
- 小〜中学校
- 生成AIとの「安全な付き合い方」「著作権・プライバシー」などの倫理教育がまず入り、
- 簡単なプロンプトを使って「要約」「箇条書き」「説明書づくり」をさせる中で、構造化された表現に触れさせる。^8_2
- 高校
- 情報I / II や探究で、プロンプト・エンジニアリングを題材に「問題を分解し、条件を整理して指示を書く」活動が増える。
- レポート作成では、「AIを使った場合、どのような構造で指示したか」「AIのアウトラインをどう修正したか」を説明させる課題が入る。^8_2
- 大学
まとめると、「構造化された文章を作る教育」が、単独で新科目になるというより、AIリテラシー／プロンプト・エンジニアリング／ライティング教育の中に埋め込まれる形で、実務的・道具的なスキルとして前面化してくる、というのが現実的なシナリオだと考えられます。^8_1^8_2
Ｑ９）では、高校卒業以上の一般人を対象とした、「AI時代における構造化された文章の入門テキスト」を作成するとしたら、その目次はどのようなものになるか、熟考した上で提示してください。
以下は、高校卒業以上の一般人を想定した「AI時代における構造化された文章の入門テキスト」の目次案です。 「AIと協働するための文章術」と「人間にとって読みやすい論理構成」の両方を意識して組んであります。
第1部 なぜ今「構造化された文章」なのか
- 第1章 AI時代の「読み書き能力」とは
1.1 読み書き算盤から「読み・書き・モデル」へ
1.2 なぜAIは“構造”を好むのか
1.3 人間にとっても構造化が有利になる理由- 第2章 「構造化された文章」とは何か
2.1 段落・見出し・箇条書きの役割
2.2 文章構造の3レイヤー：全体構成／段落構成／文構成
2.3 「ふつうの文章」と「構造化された文章」を比較する- 第3章 AIとの対話が変える“書き方の常識”
3.1 プロンプトとは「構造化された指示文」である
3.2 AIにとって読みやすい文章／読みにくい文章
3.3 AIに合わせて書くことは、人間の思考をどう変えるか
第2部 基本の型を身につける：構造化のミニマム
- 第4章 情報を「要素」に分解する
4.1 テーマを分解する：5W1HとMECEの軽い使い方
4.2 「論点」と「事実」と「意見」を分けて考える
4.3 分解からアウトラインへ：箇条書きで骨組みを作る- 第5章 段落のつくり方
5.1 1段落1メッセージの原則
5.2 トピックセンテンスと支える具体例
5.3 段落同士をつなぐ接続のパターン（原因・対比・列挙など）- 第6章 見出し・箇条書き・表で整理する
6.1 見出しが読者とAIに与えるヒント
6.2 箇条書きのルール：粒度・並べ方・順番
6.3 表で示すほうが伝わるケースとは
第3部 Markdownと軽量マークアップの実践
- 第7章 Markdownで書くということ
7.1 なぜMarkdownがAIと相性がよいのか
7.2 見出し・リスト・強調・コードブロックの基本
7.3 「プレーンテキストなのに構造が読める」書き方- 第8章 Markdownでレポートを組み立てる
8.1 シンプルなレポートの型（問題 → 分析 → 結論）
8.2 事例紹介・レビュー・メモをMarkdownで整理する
8.3 自分用ノートを「後でAIに食わせやすく」書く- 第9章 AIに渡す文章フォーマットの工夫
9.1 「ここだけ読んでほしい」を示す区切り方
9.2 質問・制約・評価基準を明示する
9.3 AI回答を前提としたテンプレート（指示→前提→出力形式）
第4部 AIと一緒に構造を磨く
- 第10章 AIにアウトラインを手伝わせる
10.1 ざっくりしたテーマから論点リストを出してもらう
10.2 AIが作ったアウトラインの良い点・悪い点を見抜く
10.3 自分の目的に合わせてアウトラインを再編成する- 第11章 AIの文章を「構造の目」で批評する
11.1 どこからどこまでが一つの主張かを線引きする
11.2 飛躍・重複・抜けをチェックする視点
11.3 「AIのたたき台 → 自分の構造」に作り替える練習- 第12章 AIに説明することで理解を深める
12.1 「素人に説明するつもりでAIに説明する」練習
12.2 自分の説明をAIに要約させ、構造をチェックする
12.3 誤解されたときにどこを直せばよいか
第5部 実生活で使う構造化文章のケーススタディ
- 第13章 仕事の文章を構造化する
13.1 報告書・議事録・提案書の基本構造
13.2 「要点だけ読める」形にするコツ
13.3 AIを活用した下書き・要約・バージョン管理- 第14章 個人の情報整理と知的生産
14.1 日々のメモを「検索しやすい」形にしておく
14.2 読書ノート・学習ログを構造化して残す
14.3 「未来の自分とAIへの手紙」としてのノート- 第15章 意見・批評・エッセイを書く
15.1 主張と根拠を分けて組み立てる
15.2 反論の予想と先回りの書き方
15.3 AIに異論を出させて、構造を強化する
終章 AI時代の「書く力」をどう育て続けるか
- 構造化スキルを習慣化するためのチェックリスト
- 「うまく書こう」とするより「うまく分解しよう」へ
- これから数年で変わるかもしれない読み書きの風景と、その中での自分の立ち位置
もしよければ、「この目次のうち、まず第◯部だけ詳しく見たい」「仕事の文章に特化した構成に絞ってほしい」など、用途を教えていただければ、それに合わせて章立てを微調整します。
Ｑ１９）良いですね。各章ごとに解説を読みたいですが、まずは巻頭の「はじめに」をお願いします。
はじめに ──AIと一緒に考える時代の「書く力」
この本は、「AIに任せる時代に、なぜ人間が“書き方”を学び直すのか？」という疑問に対する、一つの答えとして書かれています。
生成AIが一般化してから、「文章を書く」ことの風景は大きく変わりました。 数行の指示を打ち込めば、レポートもメールも企画案も、ある程度“整った日本語”で出てきます。かつて時間をかけていた「文をきれいに整える」作業は、かなりの部分をAIに任せられるようになりました。
しかし、その一方で、こんな違和感も生まれています。
- 出てきた文章はそれらしいが、本当に言いたいことと少しズレている。
- AIにうまく指示が出せず、何度もやり直してしまう。
- 量は出るのに、「自分の考え」として整理されない。
このズレの正体は、「言葉そのものの巧さ」よりも、「考え方の構造」をどう言語化するか、という部分にあります。 AIは、文法的には整っていても、前提や目的が曖昧な指示をそのまま受け取ると、“それっぽいけれど芯のぼやけた文章”を出してしまいます。逆に、前提・目的・条件・論点をきちんと分解して伝えると、驚くほど的確なアウトプットを返してくれます。
つまり、AI時代の「書く力」は、次のように少し中身を変える必要が出てきました。
- 上手に飾った文章を書く力より、
- 考えを分解し、並べ替え、骨組みをはっきりさせる力。
この本でいう「構造化された文章」とは、その骨組みを意識して書かれた文章のことです。 見出しや段落、箇条書きや表を使いながら、
- 何について
- 何を主張し
- それを支える根拠は何で
- どんな前提や条件があるのか
を、読み手とAIの両方にとって読み取りやすい形にする。 そのための、ごく基本的な「型」と「考え方」をまとめたのが、本書です。
ここで目指しているのは、プロのライター養成でも、アカデミックな論文の書き方でもありません。 高校を卒業した一般の人が、仕事や日常生活の中でAIと協働しながら、
- 伝えたいことを、相手とAIに誤解なく伝える
- AIの出してきた文章の構造を読み解き、自分に合うように組み替える
- 自分のメモやノートを、「未来の自分」と「AI」が再利用しやすい形で残す
ための、ごく実務的な「読み書きの基礎体力」です。
その意味で、本書の主役はAIではなく「あなた」です。 AIは、あなたの考えを増幅し、整理する強力な道具ですが、元になる“構造”を決めるのはあくまで人間の側です。 構造がはっきりしていればいるほど、AIも力を発揮できるし、読み手（上司・同僚・顧客・家族）にとっても理解しやすい文章になります。
本書は、次のような読者を想定しています。
- AIに文章を書かせてみたが、うまく使いこなせていないと感じる人
- 仕事のメールや報告書を、もう少しスッキリ整理して書けるようになりたい人
- 自分のメモやノートを、後からAIに読み込ませて活用したい人
各章では、小難しい理論はできるだけ避け、 「こう分けて考えると楽になる」 「こんな書き分けをするとAIの反応が変わる」 といった、感覚的に納得しやすい切り口を心がけています。
AIが文章を書いてくれる時代だからこそ、 「自分は何を、どういう構造で考えているのか」を、もう一度見直してみる。
そのための“構造化入門”として、本書を使っていただければ幸いです。
自分でも読んでみたくなったので、次回以降、第1部から順に内容を生成してもらおう。
そのうちに「著：Perplexity プロンプト作成：puis-je」みたいな書籍が出てくるようになるのかも。ここまでの作業をしていてふとそんなことを考えた。
