記事一覧

2026-09-07 22:30:00

文体を「憲法」にする — 自分の文章を分解し、直した理由をルールへ戻す

AIと小説をつくる仕組み・全8回 第4回

――「なんとなく違う」を、AIが判定できる形にする

文体を「憲法」にする — 自分の文章を分解し、直した理由をルールへ戻す

AIと小説をつくる仕組みを紹介する、全8回連載の第4回です。

前回の 「作品の目的と前提」 では、AIが作品世界に入るための入口を取り上げました。 今回は、その次に難しかった 「文体」 です。

AIに小説を書いてもらうとき、最後まで難しかったものの一つが「文体」でした。

内容については、比較的指示できます。

この場面では何が起きるのか。
誰と誰が話すのか。
主人公は何を見ているのか。
次の場面へ何を残すのか。

こうしたものは、設定ファイルやScene Planに書いておけば、AIもかなり理解してくれます。

ところが、
「どういう文章で書くのか」
となると、急に難しくなります。

文体をどうAIに渡すのか。
この1年間、かなり試行錯誤したところです。

1.自分の文を、数字にしてみた

まず、自分で文章を書いた

最初にやったのは、自分で気に入る文章を書くことでした。

自分が読んで、
「こういう文章が好きだ」
「この感じで小説を続けたい」
と思える文章を作り、それをAIに読み込ませました。

そして、その文章を分析してもらいました。

一文の長さ。
短い文と長い文の割合。
会話文と地の文の比率。
使われている言葉。
段落の長さ。
改行の仕方。
文章の流れ。

自分では「この文章が好き」としか言えなかったものを、AIに分解してもらったわけです。

その結果を、少しずつ設定ファイルに入れていきました。

現在の style_constitution.md には、たとえば一文の長さについて 平均21字、20字以下を半数、40字を超える文を6%以内 といった目安があります。地の文と会話にも比率の目安を置いています。

最初は、ここまで分析して数字にすれば、文体も再現できると思っていました。

ところが、そう簡単ではありませんでした。

条件は合っている。でも、読んでみると違う

AIに条件を渡して文章を書かせます。

一文は短い。
会話と地の文の比率も合っている。
指定したルールにも、ほぼ従っている。

それでも読んでみると、
「違うな」
と思うことがありました。

これは印象だけの話ではありません。評価レポートにも記録が残っています。 ある回の初稿につけた機械検査の結果です。

機械検査:本文3001字/数字表記・句点・『』・段落・()独白1回、すべて適合

機械的に確認できる項目は、全部通っています。 それでも同じ稿に対して、四つの評価担当がそろって同じ一箇所を指摘しました。

数字を満たしているかどうかと、読んで良いと思えるかどうかは、別のことでした。

特に多かったのが、文章が細かく切れすぎることでした。

一文。
一文。
一文。
というように、ブチブチと文章が切れてしまう。

確かに私は「短い文章」を好みます。

しかし、私が読みたかったのは、ただ短い文章を並べたものではありませんでした。

短い文がある。
少し長い文もある。
そこへ会話が入る。
地の文へ戻る。
少し間が空く。
また言葉が続く。

その流れの中に、文章の呼吸が生まれます。

文の長さを再現することと、文章のリズムを再現することは違う。

実際にAIと書いてみて、そこがよくわかりました。

たとえば、こんなところを直していた

実際によくやっていた修正を、単純化するとこんな感じです。

AIが出す文章が、

 教室の窓から風が入った。
 ルミはノートを閉じた。
 考えてみる。
 働くって、なんだろう。

となっていたとします。

一文一文に問題はありません。

でも、私なら、

 教室の窓から風が入った。ルミはノートを閉じた。
 考えてみる。
 働くって、なんだろう。

というように直します。

意味はほとんど変わりません。
変わっているのは、文章の呼吸です。

どこを続けるのか。
どこで切るのか。
どこに空白を置くのか。

現在の設定ファイルにも、「地の文は段落としてまとめる」「一文ごとに改行しない」というルールを置く一方、 心の反芻のように短文を連続させたい場合は例外としています。

ここで重要なのは、
短文が悪いわけではない
ということです。

短文を続ける場所と、続けない場所がある。
そこが文体です。

文体には「見た目」も含まれていた

文体というと、言葉遣いや文章表現を思い浮かべます。

でも、実際に作ってみると、それだけではありませんでした。

会話文のあとに地の文をどう続けるか。
地の文を何文くらい一つの段落にするか。
どこで改行するか。
地の文の段落は一字下げる。
会話文では一字下げしない。
会話文の最後に句点をつけるか、つけないか。

そうした画面で見たときの文章の形も、私にとっては文体の一部でした。

設定ファイルにも、段落の一字下げや、一文ごとに改行しないこと、 会話文の末尾には句点をつけないことなどを具体的に書いています。

一つ一つは小さなことです。

でも、それが積み重なると、読んだときの印象が変わります。

私には、
「自分ならこう書きたい」
という感覚があります。

同時に、
「自分ならこういう形で読みたい」
という感覚もあります。

この「自分なら」が、文体なのだと思います。

2.直した理由を、ルールに戻す

結局、手で直していた

AIが書いた文章を読んで、結局自分で直す。

文をつなげる。
逆に切る。
句読点を変える。
改行を変える。
会話のあとに地の文を置く。
同じ単語が続けば直す。

意味はほとんど変えず、文章の呼吸だけを変える。

そういう作業を何度もしていました。

でも、私はその手作業を減らすためにAIエージェントを使っているわけです。

AIが原稿を書き、そのあと全部自分で直していたら、なかなか自動化にはなりません。

そこで、手で直した内容を、
「次からAI自身が判断できないだろうか」
と考えるようになりました。

その結果、修正したことを一つずつルールへ戻していきました。

そうして「文体の憲法」ができた

それが、style_constitution.md です。

最初から「文体の憲法を作ろう」と考えて、完成形を設計したわけではありません。

AIに書いてもらう。
読む。
違うと感じる。
自分で直す。
なぜ直したのかを考える。
次にも使えそうなら、ルールにする。

その繰り返しでできました。

このファイルの冒頭には、

このファイルは本作品の文体と描写の憲法である。
すべてのシーンはこのルールに従う。

と書いてあります。

「憲法」と呼んでいるのは、すべてを型にはめるためではありません。

複数の指示があったとき、
この作品では、最終的にどちらを選ぶのか
を決める上位の基準だからです。

禁止するなら、代わりに何を書くかも決める

文体の憲法を作る作業と、禁止事項を作る作業は、実際には別々ではありませんでした。

たとえば、この作品では感情を名前で直接説明しない、という境界を置いています。

しかし、
「感情を書いてはいけない」
だけでは、AIは困ります。

では何を書くのか。

感情を名前で呼ばない
→ 行動を書く
→ 沈黙を書く
→ 身体の動きを書く
→ 周囲の環境を書く

というように、禁止した表現には、できるだけ代わりに使う表現をセットで渡すようにしました。

実際の 07_forbidden.md にも、感情の直接表現を禁止したあと、 「ルミは窓の外を見た」のような行動、「莉子はそれ以上何も言わなかった」のような沈黙、 身体の動き、環境描写を代替手段として置いています。

これは、AIの自由を奪うための禁止ではありません。

「こちらへは行かない。その代わり、こちら側には広い表現の余地がある」
と示すための境界です。

文体の憲法と禁止事項は、片方が「書き方」、片方が「書いてはいけないこと」なのではなく、二つを合わせて初めて、
この作品では、何をどう書くのか
をAIに渡せるようになりました。

3.それでも、同じ文体にはならない

設定ファイルに書けるのは、文体の一部

では、style_constitution.md を渡せば、いつでも私の好きな文章が出てくるのか。

1年間使ってみた現在の答えは、
そうではない
です。

同じ設定ファイルを別のAIに渡したとしても、まったく同じ文体になるとは限りません。

むしろ、ならない可能性のほうが高いと思います。

なぜなら、設定ファイルに書けるものは、文体の一部だからです。

一文をどこで切るのか。
この句読点が気になるのか。
会話のあとに、どれくらい地の文が欲しいのか。
この段落は読みやすいのか。
少し説明しすぎなのか。

そこには、作者自身の好みがあります。

しかも、その好みを作者自身が最初から全部説明できるわけではありません。

私自身も、AIの文章を読んで初めて、
「自分はここが嫌なんだ」
と気づくことが何度もありました。

AIが作者を理解していく

だから最近は、少し考え方が変わってきました。

文体を設定ファイルだけでAIに渡すのではなく、
AIが作者のことを少しずつ理解していくことも必要なのではないか
と思っています。

AIが書く。
私が直す。
なぜ直したのかを伝える。
次にまた書く。
また直す。

その繰り返しの中で、
「この作者は、こういう文章を好む」
「ここでは切らない」
「ここでは説明しすぎない」
「こういう見た目の文章を読みやすいと感じる」
という判断基準が、少しずつ共有されていきます。

設定ファイルだけが文体を作っているのではありません。
設定ファイルと、作者と、AIとのやり取り。
その3つで少しずつ文体ができていく。

だから、仮に私の style_constitution.md をそのまま別の人が使ったとしても、 私と同じ文章ができるとは限りません。

同じルール。
同じ数値。
同じ構成。

それでも、作者が違えば、
「ここを直したい」
と思う場所が違います。

その修正の積み重ねが、またAIへ返っていきます。

作者とAIとの関係そのものが、作品の文体の一部になっていく。

これは、最初にAIで小説を書き始めたときには、考えていませんでした。

私はAIに、自分の文体を教えようとしていました。

でも実際には、
AIに文章を書いてもらい、
それを自分が直し、
その理由をAIに返すことで、
AIに自分を理解してもらう作業をしていた
とも言えます。

同時に、自分自身も、
「私はこういう文章が好きだったのか」
と知ることになりました。

文体の憲法は、完成品ではない

だから、style_constitution.md は完成した文体そのものではありません。

文体を自動生成する魔法のファイルでもありません。

作者の好みをAIへ伝えるための土台です。

そして、AIとのやり取りの中で、
書き換えられ、
追加され、
少しずつ精度が上がっていくものです。

この1年間、
書く、読む、直す、ルールにする。
その繰り返しでした。

文体については、今でも完全に機械化できたとは思っていません。

むしろ、まだ課題です。

でも、
「なぜこの文章が好きなのか」
「なぜこれは違うと思うのか」
を、以前よりAIと共有できるようになりました。

それだけでも、AIと長編小説を作るうえでは、大きな変化でした。

4.該当する設定ファイル

今回の中心になるのは、次の二つです。

style_constitution.md

文体と描写の最上位ルールです。 文章の基本トーン、文の長さ、地の文と会話の比率、段落、表記などをまとめています。 ファイル自身が「本作品の文体と描写の憲法である」と定義しています。

07_forbidden.md

作品の方向から外れやすい表現について、「何を避けるか」だけではなく、 必要なところでは「代わりに何を使うか」まで定めています。

この二つを組み合わせることで、
「どう書きたいか」と「そこから外れたとき、どちらへ戻すか」
をAIと共有しています。

経営に置き換えると

「これをやるな」だけの規則は、現場で機能しません。 やってはいけないことを決めたら、代わりに何をするのかまで決める。 そこまで書いて、初めてルールとして渡せます。

もう一つ。基準を数字にしても、数字を満たしただけでは望んだ結果になりません。 数字は測るためのものであって、判断そのものではない。 最後に人が見て、なぜ違うと思ったのかを言葉にし、それを基準へ戻す。 その往復がないと、基準は作った日のまま古びていきます。

そして次に問題になったのが、文章ではなく、人間そのものです。

文章のリズムをそろえることができても、登場人物の性格が途中で変わってしまえば、 長編小説は続きません。

2026-09-04 22:54:00

AIに「この作品は何のためにあるか」を渡す — 設定ファイル01の中身

AIと小説をつくる仕組み・全8回 第3回

――AIエージェント全員が戻る、いちばん上の基準をつくる

AIに「この作品は何のためにあるか」を渡す — 設定ファイル01の中身

AIと小説をつくる仕組みを紹介する、全8回連載の第3回です。

前回の 「設定ファイルを16個に分けた話」 では、作品の情報を分けて管理する全体像を紹介しました。 今回は、その入口となる 「作品の目的と前提」 を取り上げます。

この連載でいうAIエージェントは、 執筆や評価などの役割と指示を受けて作業するAIです。

そのAIに小説を任せるとき、最初に共有したいのは、 作品が何を目指しているかです。

登場人物の名前やあらすじだけでは、 場面をどう描き、何を基準に直すかの判断まではそろいません。

そこで用意しているのが、 「作品の目的と前提」という設定ファイルです。 AIが作品世界に入るための入口であり、 判断に迷ったときに戻る基準でもあります。

最上位の目的を共有する

『13歳、わたしはお金持ちになると決めた。100の問い』では、 最上位の目的を 「人間が変わる一回分を、物語としてシミュレートすること」 と定めています。

登場人物をある状況に置く。 そこから感情が生まれ、小さな行動につながる。 行動には結果が返り、問いが残る。 このつながりを、各回の土台にしています。

設定ファイルでは、品質の物差しを 「人間は本当にこう変わるか」 としています。

読み違えたり、体験をうまく言葉にできなかったりすることも、 その人物にとって自然なら残します。 執筆担当にも評価担当にも、この基準を渡します。

実際に、Q44のv2の評価で指摘されたのは、 地の文の採点癖でした。

理由になっているような、なっていないような答えだった。

この一文は、登場人物の答えを、 読者が受け取るより先に地の文が採点しています。

答えの曖昧さをそのまま置けば、 読者は会話から自分で受け取れます。 ところが、語り手が評価を添えると、その余白が狭まります。

興味深いのは、この一文が 総合88点の稿にも残っていたことです。

点数上の承認基準は85点以上で、 評価レポートでも承認可能とされていました。 それでもv4で再び指摘され、 最終的な確定稿で削除しました。

v4で指摘された地の文は3か所あり、 削除したのは2つ、1つは残しています。

「理由になっているような、なっていないような答えだった」と 「閉じても、遅かった」は削除し、 「長く感じた」は残しました。

点数だけで判断が決まるわけではありません。

AIの指摘を受け取り、 「人間は本当にこう変わるか」という最上位の目的に照らして、 最後は書き手が選びます。

作品の目的を共有する意味は、こうした検討にもあります。

「経験の意味を説明しすぎない」という文体の規則とつなげることで、 AIは具体的な一文を指摘できる。 書き手も、その指摘を採用するかどうかを、 作品全体の基準に戻って考えられます。

人物が持ち込む願いを渡す

作品の目的だけでは、人物ごとの動きは決まりません。 そこで、このファイルには、 二人が物語に持ち込む願いも記しています。

人物 出発点 相手の家庭に求めるもの
ルミ お金があれば遠慮しなくていい 経営の知恵や、成功した環境
莉子 好きなことがわからない 愛と調和のある温かさ

二人は同じ目標へ向かっていても、 同じものを求めているわけではありません。 その違いが、協力にもすれ違いにもつながります。

AIには、こうした背景を 台詞や行動を選ぶ根拠として使ってもらいます。

人物の性格を「明るい」「慎重」といった言葉で覚えるだけでなく、 何に惹かれ、何を手に入れようとしているのか まで共有しておくためです。

物語全体の到達点も記しています。

本作では、二人がパン屋さんを事業として成功させ、 その後に、成功だけでは対処できない出来事へ向き合います。

この順序を共有しておかないと、 目の前の回を盛り上げるための変更が、 長期的な設計を崩しかねません。

GraceというAIコーチの役割も、その前提のひとつです。

前半はルミに問いを返し、 後半は二人の実践を支える共同コーチになります。 支援の方法が変わっても、 選択と行動の主体は二人に残ります。

ここを共有することで、 Graceの提案だけで物語が進むことを防ぎます。

AIに伝えることと、読者に伏せること

設定ファイルには、 作品の奥にある問いや終盤の設計まで記しています。 執筆するAIには、全体を理解してもらう必要があるからです。

ただし、 それを本文のどこで読者に伝えるかは別の判断です。

たとえば、莉子がルミの家庭に何を求めているのかは、 制作側が共有する情報です。

本文では莉子の内面を直接説明せず、 言葉、視線、動作、沈黙を通して描きます。

AIが背景を知っているからといって、 その知識を地の文に書いてよいわけではありません。

作品が最後に向き合う問いも同様です。 読者には、まず二人の商売や関係の行方を追ってもらいます。

テーマを先回りして説明すると、 出来事に直面して考える機会を奪ってしまいます。

設定ファイルには、 「知っておくべきこと」と 「まだ書いてはいけないこと」の両方 が必要です。

全体を知るAIが、 その時点のルミに見える範囲で場面を書く。 その境界を支えるのも、このファイルの役割です。

他のファイルとつなげて使う

「作品の目的と前提」には、 すべての指示を詰め込んでいません。

人物の詳細、禁止事項、文体、各回の場面設計、 確定済みの出来事は、 それぞれ別のファイルで管理しています。

このファイルは、 それらを読むときの共通の土台です。

Q44の例でも、 作品の目的だけで修正箇所が決まるわけではありません。

「経験の意味を説明しすぎない」という文体の規則と照らし合わせることで、 具体的な一文への指摘になります。

大きな目的と細かな規則をつなげて使うことが、 執筆と評価の判断をそろえます。

担当するAIや執筆する回が変わっても、 「この作品は何を目指しているのか」に戻れるようにする。

そのために、作品世界への入口をファイルとして用意しています。

該当する設定ファイル

01_premise.md

作品の最上位の目的、核心となる問い、 ルミと莉子の出発点、二つの家庭の対比、 パン屋さんの位置づけ、Graceの役割、 読者に届けたい体験、物語の到達点をまとめています。

AIエージェントが場面を書く前に読み、 作品全体の方向を確認するためのファイルです。

関連する 00_priority.md は、 設定同士が食い違った場合の優先順位を定めています。

後半の詳細は、 14_simulation_phase_q51_100.md が Graceとの共同実践や終盤の進め方を、 15_mobile_bakery_reality.md が パン屋さんの責任体制、安全、採算、成功条件を定めています。

2026-09-02 22:01:00

AIに長編小説を書かせ続けるために、設定ファイルを16個に分けた話

AIと小説をつくる仕組み・全8回 第2回

――人間が毎回していた確認を、AIエージェントの制作工程に変える

生成AI、役割を分けたAIエージェント、設定ファイル、人間の判断の関係を表したインフォグラフィック
設定ファイルを共通の基準にして、執筆・評価・整合性確認を分担し、最後は人間が判断します。

この記事の要点

生成AIは、同じ指示からも毎回少しずつ違う文章を作ります。 長編では、その小さな違いが人物や時系列の矛盾として積み重なります。 そこで私は、人間が毎回行っていた確認を役割に分け、 執筆・4つの評価・整合性確認・統合をAIエージェントに担当させました。

全エージェントが同じ作品へ戻れるよう、『13歳、わたしはお金持ちになると決めた。100の問い』Q1〜Q50では設定を16個のファイルに分けて管理しました。 実際に起きた修正と見逃しの両方から、設定ファイルを運用する意味とコストを紹介します。

この記事を貫く4つのポイント
  1. 文章生成とエージェント執筆は、作業の範囲が違う
  2. 設定ファイルは、複数のAIが共有する判断基準になる
  3. Q44では、初稿84点が改稿で88点になり、さらに過去稿との照合で二つの不整合を直した
  4. 16ファイルの運用には、更新漏れや古い設定を残すリスクもある

1.AIによる文章生成と、AIエージェントによる執筆の違い

生成AIに「小説を書いてください」と頼めば、文章はすぐに生成されます。

ただし生成AIは、完成した答えを保管場所から取り出しているのではありません。 入力された指示や資料を文脈として読み、次に続く言葉の候補を確率的に選びながら文章を組み立てます。

同じ指示を与えても、
言葉、場面の順序、会話、結末まで同じになるとは限りません。

この性質は、短い文章では表現の豊かさになります。 一方、長編小説では小さな違いが積み重なり、人物の性格、過去の出来事、日付、伏線などのずれになります。

チャットで小説を書き始めたころ、AIが原稿を出すたびに、私は次のことを人間の目で確認していました。

  • ルミと莉子の性格や話し方が変わっていないか
  • 前の回で起きた出来事と矛盾していないか
  • 莉子の内面を、ルミには分からない地の文で説明していないか
  • 物語の問いを、登場人物が教訓として説明していないか
  • 会話や情景が、作品の文体から外れていないか

つまり私は、依頼者であると同時に、編集者、校閲者、設定管理者、初見読者の役割も引き受けていました。

そこで、この確認作業を分解し、それぞれに参照資料と手順を与えました。 これが、私の小説制作におけるAIエージェントです。

AIエージェントによる小説制作工程 執筆した原稿を4つの視点で評価し、整合性を確認してから評価を統合し、最後に人間が判断する流れ 執筆エージェント 4つの評価エージェント 創造性 読者体験 会話 情景 整合性を確認 評価を統合 最後は人間が判断
AIが自動的に完成を決めるのではなく、役割ごとの結果を材料に、改稿するか承認するかを人間が決めます。

2.設定ファイルはAIエージェントのガードレール

役割を分けても、それぞれのエージェントが別の作品像を持っていたら、判断は安定しません。 全員が同じ基準へ戻るために必要なのが設定ファイルです。

設定ファイルは、AIに覚えさせるためのメモではなく、
迷ったときに参照する作品の判断基準です。

道路のガードレールは、車の進む方向を一つに固定するものではありません。 進む自由を残しながら、越えてはいけない境界を示します。

小説の設定ファイルも同じです。 AIに会話や情景を考える自由を残しながら、人物の核心、視点、時系列、禁止事項から外れたときに、同じ作品へ戻します。

たとえば、この作品の文体を定める style_constitution.md には、実際に次のように書いてあります。

文体はシンプル
感情を直接書かない
行動・沈黙・環境描写で感情を示す
行間に感情が流れる文章にする

これは「美しい文章を書いて」という抽象的な依頼ではありません。 執筆担当には書き方の境界を示し、評価担当には原稿を判定する基準を渡しています。

Q44で、過去稿とのずれを二つ直した

設定ファイルが実際に働いた例が、問い44「『ありがとう』はどれくらい伝えてる?」です。 「ありがとう」を問うこの回で、ルミは莉子に八つ当たりをします。

Q44を改稿していた段階で、ルミの八つ当たりの中に、過去の「ヒナタ」の出来事を入れる案がありました。 しかしQ8の確定稿と照合すると、現在の場面からその言及へつなぐと、過去に起きたことの扱いがずれます。 そこで、ヒナタへの言及は使わないと決め、13_details.md に記録しました。

もう一つは、自動販売機です。 Q44では、過去の場面を響かせるためにミルクティーの見本を出す案がありました。 ところがQ17とQ29の確定稿を読み直し、同じ自動販売機に重なっている二つの記憶を整理した結果、 Q44では「りんごジュースの缶」を使うことにしました。

過去の要約や記憶から場面を作る
↓
Q8・Q17・Q29の確定稿と照合する
↓
ヒナタへの言及を削除する
↓
ミルクティーを、りんごジュースの缶へ修正する
↓
判断と教訓を 13_details.md に残す

Q44の初稿は総合84点でした。 この総合点は、創造性、初見の読者体験、会話の複雑さ、情景と感情という4つの評価を加重平均して算出しています。 承認基準は85点以上です。84点は改稿、88点で承認可能という意味になります。

4つの評価で指摘された八つ当たりの長台詞、比喩による感情の説明などを修正した次の稿は88点になりました。 整合性確認は総合点には加えず、作品の重大な矛盾を止める別のゲートとして通過判定を行います。 このゲートで、過去の実発話との差を含む初稿のずれが解消されたことも確認しました。

その後の作者編集で、確定稿をさらに照合し、ヒナタへの言及を削除して、ミルクティーをりんごジュースの缶へ変更しました。 84点から88点への上昇と、この二つの不整合修正は、同じQ44の制作中に起きた別の改善です。

Q44は、4評価による改稿で84点から88点へ。
その後、過去稿との照合による二つの修正も設定へ残しました。

ここで得た一番大きな教訓は、AIや人間の記憶から過去を再現しないことでした。 過去の場面に依存する描写は、要約ではなく確定稿そのものと照合する必要があります。

3.設定ファイルの基本構成と、実際の運用コスト

設定ファイルは、情報を多く書けばよいわけではありません。 AIが必要なときに、正しい基準と現在地を見つけられる構造にする必要があります。

設定の種類 記録する内容 主な目的
作品の核 目的、前提、全体構造、100の問い 何のための物語かを見失わない
人物と世界 人物、欲望、弱点、関係、場所 人物らしさと舞台を保つ
表現のルール 視点、文体、表記、禁止事項 文章の手触りと境界を守る
場面の設計 各章の出来事、固定アンカー、場面の核 全体構成を一回分の場面へ落とす
物語の現在地 確定した出来事、日付、数値、小道具 古い情報との混同を防ぐ
確認の基準 人物、文体、整合性のチェック項目 人間がしていた確認を再現する

運用では、変わりにくい設定と、毎回更新される現在地を分けています。

変わりにくい設定
作品の目的・人物の核心・視点・禁止事項

更新される現在地
出来事・日付・数値・関係の変化・小道具の状態

一回分の原稿を承認するときは、本文を確定するだけでは終わりません。 時系列を管理する 10_timeline.md と、確定事実を管理する 12_glossary.md も同時に更新します。

この作業には明確なコストがあります。 16個に分ければ自動的に安全になるわけではなく、更新する場所が増え、古い記述を残す危険も増えます。

Q49では、矛盾が確定稿まで残った

実際、Q49では「この高校、大学まであるんだって」「内申って、2年から関係ある?」という、 高校受験を前提にした会話が確定稿まで残りました。

しかし、ルミと莉子の学校は私立の中高一貫校です。 作品の学校設定と、場面で使った進路の話題が一致していませんでした。

この矛盾は、設定ファイルがあれば失敗しない、という話ではないことを示しています。 ファイルがあっても、読む範囲、照合の順序、更新のタイミングが足りなければ、矛盾は通過します。

しかもQ49は、すでに公開された確定稿でした。 既刊を購入した読者がいる以上、手元の本文だけを黙って書き換えれば、同じ作品に異なる内容が併存してしまいます。 そこで本文を修正せず、12_glossary.md に「既知の差異」として登録しました。 以後は高校受験や内申を前提にした描写を広げず、進路の話題をコース分け、学年順位、模試、塾、その先の大学に限る運用にしました。

設定ファイルは、失敗をゼロにする魔法ではありません。
失敗を発見し、次の回へ広げず、修正方針を共有するための仕組みです。

Q44では改稿の精度を上げることができました。 Q49では見逃しも起きました。 成功例と失敗例の両方を残すことで、どの確認工程を強くするべきかが見えるようになります。

4.Q1〜Q50で使った16個の設定ファイル

『13歳、わたしはお金持ちになると決めた。100の問い』では、 一つの巨大なプロンプトに設定を詰め込まず、Q1〜Q50を次の16個のファイルで支えました。

ここでいう「16個」は、役割上の16種類という数え方です。 09_scene_plan_chX.md は一種類として数えていますが、実体は章ごとに作成・更新します。

ファイル 実際の役割
00_priority.md 設定同士が衝突したとき、どの指示を優先するかを決める
01_premise.md 作品の目的、前提、物語の中心となる考えを定める
02_characters.md ルミ、莉子、家族の人物像、欲望、弱点、言動の境界を管理する
03_structure.md 100の問いを10章へ配置し、物語全体の進行と転換点を示す
04_style.md ルミの三人称視点と、書いてよい内面の範囲を定める
05_questions_bank.md 各問いの番号、章との対応、物語内での問いの扱いを管理する
06_locations.md 家、学校、街などの場所と、その場所が持つ条件を記録する
07_forbidden.md 直接説明しないテーマ、避ける表現、越えてはいけない描写を定める
08_style_guide.md 実際の原稿から、文章の長さ、改行、会話、数字表記を具体化する
09_scene_plan_chX.md 各章を場面へ分解し、必ず入れる固定アンカーと表現メモを区別する
10_timeline.md 季節、日付、経過時間、各回で起きた出来事の順序を管理する
11_friendship_arc.md ルミと莉子の友情が、一方通行から双方向へ変わる過程を追う
12_glossary.md 確定した数値、呼称、小道具、関係の現在状態、既知の差異を管理する
13_details.md 描写の取材情報を確定・未確認・検証済みに分け、失敗から得た教訓も残す
style_constitution.md 文体と描写の憲法。感情を説明せず、行動・沈黙・環境から立ち上げる
character_check.md 主人公が自分から動き、欲望と弱点が場面に現れているかを確認する

ファイルを分ける目的は、AIに大量の情報を読ませることではありません。 執筆、評価、整合性確認のそれぞれが、必要なときに必要な正しい情報へ戻れるようにすることです。

ファイルの数より大切なのは、
何を正とし、いつ読み、いつ更新するかを決めることです。

Q1〜Q50では、グレースはルミの相談相手でした。 物語の中心は、ルミが莉子や家族との関係の中で体験し、行動し、その結果として問いを見つけることでした。

Q51以降では、グレースの役割も物語の進め方も変わります。 相談相手から、ルミと莉子にドリルを出し、結果に応じて計画を組み直す共同コーチへ。 そして物語は、移動式パン屋を現実の事業として立ち上げるシミュレーションへ移ります。

その転換に合わせて、どの設定を残し、どの設定を区切り、何を新しく加えたのか。 次の記事から、設定ファイルを詳しく紹介します。

今回参照した制作資料

  • Q8、Q17、Q29、Q44、Q49の確定稿と評価レポート
  • 13_details.md のQ44場面シートと更新履歴
  • 12_glossary.md の確定事実、関係の現在状態、既知の差異
  • style_constitution.md とQ1〜Q50の作品設定ファイル
  • 執筆・4評価・整合性確認・統合評価のエージェント定義

この記事は、生成AI一般の唯一の使い方を示すものではありません。 一つの長編小説をAIと継続して制作するために、私が実際に組み立て、失敗しながら更新してきた方法 をもとにまとめています。

2026-08-27 20:01:00

AIと一緒にMicrosoftの道具箱をひっくり返してみた

AIと一緒にMicrosoftの道具箱をひっくり返してみた

――会員サイトを作ろうとして見えてきた、つながる仕組み

会員サイトの設計をもとに、SharePoint、Teams、Forms、Power Automate、Entra ID、Purview、AzureなどMicrosoftのサービスをつないでいく仕組みを表したインフォグラフィック
会員サイトの設計を先に考え、その実現に必要なMicrosoftの道具を一つずつ探してつないでいきました。

この記事の要点

Digital Supporters Clubの会員サイトを作るために、 まず設計書を書き、その設計を実現する道具をMicrosoftの製品群から探していきました。

そこで分かったのは、Microsoft 365にはたくさんの機能が揃っているだけではなく、 管理者側で認証や権限の仕組みを理解すると、それぞれをつなげて一つのサービスとして使える ということでした。

そして今は、分からないことを一緒に調べ、設計し、試してくれる ChatGPTやClaudeのような「技術に詳しい同僚AI」がいます。

プログラマーとして仕事をしてきたわけではない私でも、 AIと一緒に確認しながら、実際に仕組みをつないで動かすところまで体験できました。

この記事を貫く4つのポイント
  1. 最初に作ったのは、Microsoftの勉強計画ではなく会員サイトの設計書
  2. Microsoftの強さは「道具が多い」だけでなく「道具同士がつながる」こと
  3. 管理者側を理解すると、認証・権限・監査まで含めて一つの仕組みにできる
  4. AIと一緒なら、知らない技術も調べ、確認し、試しながら理解できる

1.最初に作ったのは、会員サイトの設計書だった

Digital Supporters Clubでは、

「AIと、一緒に。書いてみたいことを、形にしよう。」

という考え方で、小説、エッセイ、自分史、思い出、体験などを書いてみたい人が、 少しずつ自分の言葉を形にしていける場所を作ろうとしています。

今回の出発点は、 Microsoft 365を勉強することではありませんでした。

最初に考えたのは、

どんな会員サイトにしたいのか

ということです。

会員には、自分だけの原稿を書く場所がある。

書いたものを保存して、続きを書ける。

完成した作品は、ほかの会員に公開できる。

ほかの会員は作品を読めるけれど、 勝手に編集することはできない。

読んだ人は感想を残せる。

作品を取り下げても、元の原稿は残す。

届いた感想も大切に残す。

こうしたことを一つずつ設計書に書いていきました。

会員サイトの中心となる体験は、

書く
↓
保存する
↓
続きを書く
↓
公開する
↓
感想が届く
↓
また書く

という流れです。

つまり、 製品から考えたわけではありません。

先に「こうしたい」という設計があり、
そのあとで必要な道具を探した。

この順番でした。

設計ができたところで、

「さて、これを実現するには何を使えばいいのだろう」

と、Microsoftの道具箱をひっくり返してみました。

2.中心に置いたのはSharePointだった

最初に中心になったのはSharePointでした。

以前の私にとってSharePointは、 どちらかというと、

会社でファイルを共有する場所

という印象でした。

ところが、自分で管理者側から触ってみると、 ずいぶん違って見えました。

文書を保存できる。

フォルダを作れる。

履歴も残せる。

そして、 誰に見せるのか、 誰に編集させるのかを細かく決めることができます。

そこでDigital Supporters Clubでは、 SharePointの中に、

自分の作品を書く
本人専用

みんなの作品
会員向け公開

という二つの場所を分けて作ることにしました。

本人専用の場所は、 本人と管理者だけがアクセスできます。

公開側では、 作者は自分の作品を編集できる。

ほかの会員は読むことはできるけれど、 編集することはできない。

つまりSharePointを単なるファイル置き場としてではなく、

会員サイトの情報と権限の中心

として使うことにしました。

ここまで来ると、 次の疑問が出てきます。

入会申込はどうするのか。

会員をどう識別するのか。

承認はどうするのか。

感想はどこで受け取るのか。

管理作業が増えたらどうするのか。

そこで、Microsoftの道具箱をさらにひっくり返していきました。

3.道具箱から、これだけのものが出てきた

今回の会員サイトづくりで登場した主なMicrosoftのサービスを並べてみます。

自分でも、こうして一覧にすると驚きます。

製品・機能 今回の役割
SharePoint Online 会員サイトの中心。原稿、公開作品、アクセス権を管理する
Microsoft Teams お知らせや、作品への感想をやり取りする
Microsoft Forms 入会申込を受け付ける
Power Automate Forms、承認、通知などの処理をつなぐ
Approvals 管理者が入会を承認・却下する
Microsoft Entra ID 会員やアプリの「身元」と「できること」を管理する
Microsoft Graph Microsoft 365の情報をプログラムから扱うための窓口
SharePoint REST API SharePointをプログラムから操作するための窓口
Microsoft Purview Audit Microsoft 365上で行われた操作の記録を確認する
Azure Functions DSC Builderのプログラムを動かす
Azure Key Vault 証明書やAPIキーなどの秘密情報を保管する
Managed Identity Azureのサービス同士を、パスワードを直接渡さず認証する仕組み
Application Insights プログラムの実行結果やエラーを確認する
Sites.Selected アプリが操作できるSharePointサイトを限定する仕組み

もちろん、 これらすべてがMicrosoft 365 Business Basicの料金だけに含まれているわけではありません。

Azure FunctionsやKey Vaultなど、 Azure側のサービスは別途従量課金です。

Purviewについても、 利用できる機能やログの保持期間などはライセンスによって異なります。

それでも、 会員サイトの中心となるSharePoint、Teams、Formsなどを、 比較的低価格なMicrosoft 365のプランから使い始めることができます。

2026年8月現在、 Teamsを含むMicrosoft 365 Business Basicは、 Microsoft公式サイトで年間契約の場合、

1ユーザーあたり月額1,049円相当、税別

と案内されています。

最近は、お昼を食べても1,000円を超えることが珍しくありません。

ランチ1回ほどの金額で、 これほど大きな道具箱を毎月使える。

これは、あらためて考えるとかなりすごいことだと思います。

Microsoft公式「Microsoft 365 Business Basic」

4.本当に驚いたのは「道具の数」ではなく「つながること」

ただ、今回いちばん驚いたのは、 Microsoftに製品がたくさんあることではありませんでした。

それらを、つなげて使えることです。

Digital Supporters Clubでは、 たとえばこんな流れになります。

Microsoft Forms
入会申込

↓

Power Automate / Approvals
管理者による承認

↓

Microsoft Entra ID
会員を識別

↓

SharePoint
書く・保存する・公開する

↓

Teams
感想を受け取る

↓

Azure Functions
管理作業を支援する

↓

Key Vault
秘密情報を守る

↓

Application Insights
処理結果を確認する

↓

Microsoft Purview Audit
利用の記録を見る

Purviewでは、 Microsoft 365上で行われた操作の記録を確認できます。

Digital Supporters Clubでは将来的に、 SharePointのページを見た、 ファイルを開いた、といった記録から、

「この会員が最後にDigital Supporters Clubを利用したのはいつか」

を確認することまで設計しています。

現在の試作では、 まずSharePointの読み取りと新規会員セットアップまでを作っています。

Purviewとの自動連携は、 その試作を評価してからの次の段階です。

それでも、

入会する
↓
本人を識別する
↓
書く
↓
保存する
↓
公開する
↓
感想を受け取る
↓
管理する
↓
何が起きたかを記録する

ここまでをMicrosoftのサービスで一本につなげられる。

これが、 道具箱をひっくり返してみて一番驚いたことでした。

5.管理者側に立って、初めて「つなげ方」が見えた

そして今回、 もう一つ大きな発見がありました。

それが、

Microsoft 365を管理者側から見たこと

です。

大きな組織や行政でMicrosoft 365を使っていると、 管理者の仕事は情報システム部門やベンダーが担当することが多いと思います。

一般の利用者には、 必要な機能だけが提供されます。

Teamsはこちら。

SharePointはこちら。

このフォルダを使ってください。

それは、安全に運用するためには当然のことです。

ただ、それだけを使っていると、

Microsoft 365という仕組みが、本来どこまでできるのか

は、なかなか見えてきません。

私自身もそうでした。

今回、自分で管理者側に入り、

  • 外部の人をどう参加させるのか
  • 誰にどの権限を与えるのか
  • アプリからSharePointへどう接続するのか
  • アプリにはどこまで操作を許すのか
  • 何が行われたかをどこで監査するのか

と、一つずつ見ていきました。

そこで初めて分かったことがあります。

サービス同士をつなぐには、
機能を知っているだけでは足りない。
認証と権限を理解する必要がある。

FormsとPower Automateをつなぐ。

Entra IDとSharePointをつなぐ。

Azure FunctionsとMicrosoft 365をつなぐ。

Purviewで、その利用記録を見る。

こうした接続には必ず、

  • 誰が接続しているのか
  • 何をすることが許されているのか
  • どこまでアクセスしてよいのか

という問題が出てきます。

ここを理解できるようになったことで、 Microsoftの各製品が、 ばらばらのアプリではなく、

一つのシステムを作るための部品

として見えるようになりました。

そして管理者権限についても、 印象が変わりました。

管理者権限は、 何でもできるようにするための権限ではありません。

必要な人に、必要な範囲だけ権限を与えるために使う。

今回のDSC Builderでも、 Microsoft 365全体を自由に操作できるようにはしていません。

Digital Supporters ClubのSharePointサイトだけに、 操作できる範囲を限定しました。

管理者側を知ることで、

「何ができるか」だけではなく、
「どこまでできるようにするか」を設計できる。

そして、それがサービス同士を安全につなぐことにつながります。

6.APIも、実際につないでみて分かった

サービス同士をつないでいく中で、 これまで少し遠い言葉だった「API」の意味も、 だんだん実感として分かるようになりました。

APIとは簡単に言えば、

プログラム同士が情報をやり取りするための窓口

です。

普段Webサービスを使っていると、 私たちが見るのは表側です。

ブラウザを開く。

ボタンを押す。

入力する。

保存する。

その裏側で、 プログラム同士がどう話しているのかを見る必要はありません。

今回、自分でDSC Builderを作って、 初めてAPIが実感として分かりました。

私がAIに、

「この会員のSharePointフォルダを準備して」

と頼む。

AIが専用APIへ依頼する。

Azure Functionsで動いているプログラムが、 SharePointのAPIへ依頼する。

SharePointが処理する。

そして結果が戻ってくる。

そこで、

「ああ、APIというのは、プログラム同士が話をするための窓口なんだ」

と腑に落ちました。

教科書で定義を読むより、 自分でつないで動かしてみる方がずっと分かりやすかったのです。

Azureについても同じでした。

プログラムを動かす
Azure Functions

秘密情報を守る
Key Vault

実行状況を見る
Application Insights

というように、 必要な機能をサービス単位で組み合わせました。

Azureを使っているのに、 あまり「サーバーを作っている」という感覚がありません。

これも実際に触ってみて初めて分かったことでした。

7.AIは、技術に詳しい同僚のようだった

ここまでできた背景には、 もちろんAIがあります。

私はプログラマーとして仕事をしてきたわけではありません。

今回も、

  • API
  • REST
  • Entra ID
  • 証明書認証
  • Managed Identity
  • Sites.Selected

と、知らない言葉が次々に出てきました。

以前なら、 そのたびにマニュアルを探していたと思います。

説明を読む。

分からない言葉が出てくる。

その言葉を検索する。

すると、また知らない言葉が出てくる。

どこかで、

「これは自分には難しい」

と思っていたかもしれません。

今は、ChatGPTやClaudeに、

  • 「そもそもAPIって何?」
  • 「なぜここに認証が必要なの?」
  • 「この権限は広すぎない?」
  • 「今の構成を初心者にも分かるように説明して」

と、その場で相談できます。

そして、 単に答えを教えてもらうだけではありません。

一緒に設計を考える
↓
設定する
↓
エラーの原因を考える
↓
公式資料を調べる
↓
実際に動かして確認する
↓
また修正する

今回の感覚に近いのは、

技術に詳しい同僚AIが隣にいて、一緒に作業している

というものでした。

もちろん、 AIの答えがいつも正しいとは限りません。

特に認証や権限、 Microsoftのサービス仕様のような重要な部分は、 Microsoftの公式資料を確認し、 最後は実際の環境で動作を確かめる必要があります。

今回も、

AIに聞く
↓
公式情報を確認する
↓
実際に試す
↓
結果を見る

ということを何度も繰り返しました。

AIに全部任せるのではなく、

詳しい同僚と一緒に考えながら、
自分自身も理解していく。

そんな使い方が、 確かに私には合っていました。

8.今回一番大きかったのは、管理者側を自分で触ったこと

今回の会員サイトは、 まだ開発の途中です。

でも、0次開発をやってみて、 自分の中ではMicrosoft 365の見え方がかなり変わりました。

以前なら、

SharePointはファイル置き場
Teamsは会議やチャット
Azureはエンジニアが使うもの
APIはプログラマーの世界
管理者画面は専門家やベンダーが触るもの

そんなふうに、 別々のものとして見えていました。

今回、先に会員サイトの設計書を書きました。

その設計を実現するために、 Microsoftの道具箱をひっくり返しました。

必要な道具を見つけました。

そして管理者側に入り、 認証や権限を理解しながら、 それぞれをつないでみました。

分からないところはAIと一緒に調べました。

公式資料でも確認しました。

そして実際に動かしました。

そこで一番強く感じたのは、

Microsoft 365は、
用意された機能を利用者として使うだけでは、
ほんの一部分しか見えない。

ということです。

もちろん、 組織で利用するときに管理者権限を誰にでも渡すべきだとは思いません。

強い権限だからこそ、 厳しく管理する必要があります。

ただ、自分で何かサービスを作ろうとするなら、

管理者側で何ができるのかを、
自分自身でも理解しておくことはとても大切だ。

と今回あらためて感じました。

管理者の部分をすべてベンダーに任せれば、 安全で楽な面もあります。

でも、それだけでは、

  • このサービスと、このサービスはつなげられる
  • ここまで権限を絞れる
  • このログを使えば、こんな運用ができる

という発想そのものが出てこないことがあります。

今回、管理者権限を持ってMicrosoft 365の中を実際に見たことで、

たくさんの道具があることだけでなく、
その道具をどう安全につなげれば
一つのサービスになるのか

が、少しずつ分かってきました。

月1,000円ほどのMicrosoft 365の道具箱。

必要な分だけ使えるAzure。

そして、 分からないところを一緒に考えてくれる同僚AI。

これらも大きな助けでした。

でも、今回の経験から私が最後に残したいのは、 もっと単純なことです。

自分でサービスを作りたいなら、
管理者側を人任せにしすぎず、
一度は自分で触って、何ができるのかを知っておく。

そして、 強い権限だからこそ、 その意味を理解し、 必要な範囲に絞って使う。

そのことの大切さを、 Digital Supporters Clubの会員サイトづくりを通して、 あらためて実感しました。

参考にした公式情報

この記事は、Microsoft製品を網羅的に解説することを目的としたものではありません。 Digital Supporters Clubの会員サイトを実際に設計し、必要なMicrosoftのサービスを一つずつつないでいった体験 をもとに書きました。
さて、Club会員サイトのメーキングストーリーはこのぐらいでお終いにします。
次回以降は、AI小説制作のテクニカルなお話をしたいと考えています。

2026-08-23 20:51:00

Claude in Chrome と GPTを比べてみた

Claude in Chrome と GPTを比べてみた

――AIに仕事を任せる、二つのまったく違う方法

Claude in ChromeとGPTという二つのAIエージェントの仕組みや特徴を比較したインフォグラフィック
ブラウザを直接操作するClaude in Chromeと、APIを通じて専用の仕事を行うGPT。二つは同じAIエージェントでも、設計思想が大きく異なります。

この記事の要点

前回までの記事で、Digital Supporters Clubの運営を支援する 「DSC Builder GPT」をつくってきました。

SharePointに会員用のフォルダをつくり、 決められたアクセス権を設定し、 最後に本当に正しく設定されたかを確認する。

ようやく、実際に動くところまでたどり着きました。

そこで今回は少し視点を広げ、 私が実際に作ったり使ったりした二つのAIエージェントを比較します。

一つは、今回つくったDSC Builder GPTのように、 APIを通じて、あらかじめ決められた仕事を行うタイプ。

もう一つは、Claude in Chromeのように、 AIがブラウザを見ながら人間の代わりに画面を操作するタイプです。

これは「ClaudeとGPTのどちらのAIモデルが賢いか」という比較ではありません。

Claude in Chromeというブラウザ操作型のAIエージェントと、 Custom GPT+Actions/APIでつくった専用型AIエージェントの比較です。

この記事を貫く4つの比較軸
  1. GPT型は「サービスをAIへつなぐ」
  2. Claude in Chrome型は「AIがサービスへ出かけていく」
  3. 自由度と安全性では、手綱を置く場所が違う
  4. どちらが優れているかではなく、向いている仕事が違う

1.そもそもAIエージェントとは何なのか

私は、AIエージェントを難しく考えず、

自分の代理人として、実際の仕事までしてくれるAI

と考えると分かりやすいと思っています。

これまでChatGPTを使うときは、 プロンプトで相談することが中心でした。

「これについて調べて」

「どうすればいい?」

「文章を書いて」

「SharePointではどう設定すればいい?」

AIが答えてくれる。

しかし、その答えを読んで、 実際にSharePointを開いて操作するのは自分です。

つまりAIは非常に優秀な相談相手でしたが、 仕事は最後に人間へ戻ってきました。

AIエージェントでは、 この関係が少し変わります。

「どうすればいい?」ではなく、
「これをやっておいて」と頼める。

たとえば、

「この会員が使うフォルダを準備しておいて」

と頼む。

するとAIが、自分の代わりにシステムへ働きかけ、 実際に仕事を進めます。

私はこの、

「教えて」から「やっておいて」への変化

が、AIエージェントを理解する一番分かりやすい入口だと思っています。

2.GPTが登場したとき、「AIのApp Store」が始まるように見えた

ここで少し時間を戻します。

OpenAIがGPTsを発表したのは、2023年11月でした。

特定の目的に合わせたChatGPTを、 専門的なプログラミングをしなくても作れる。

それを他の人と共有できる。

さらにActionsを使えば、 外部のAPIにつなぎ、 データを取得したり、 外部システムを動かしたりすることもできる。

そして、それらのGPTを探して使える 「GPT Store」も発表されました。

2024年1月にGPT Storeが公開されたときには、 OpenAIによれば、すでに300万を超えるカスタムGPTが作られていました。

当時は、

これからChatGPTそのものが、一つの大きなプラットフォームになっていくのではないか

という期待が大きく広がりました。

スマートフォンにアプリを追加するように、 ChatGPTの中にさまざまな専門GPTが並ぶ。

旅行のGPT。

会計のGPT。

教育のGPT。

会社独自のGPT。

そして必要なら、 それぞれが外部サービスのAPIにつながる。

考え方としては、

世の中のさまざまなサービスを、AIの側へつないでいく

方向です。

今回つくったDSC Builder GPTも、 まさにこの考え方の延長にあります。

3.DSC Builder GPT――「できる仕事」を先に定義する

DSC Builderでは、 GPTからSharePointを自由に操作できるようにはしていません。

たとえば、

「DSC0007として、この会員を準備して」

と頼む。

GPTは専用APIへ依頼します。

API側では、

  • どのSharePointサイトを操作できるか
  • どのフォルダを作れるか
  • どんな会員番号を受け付けるか
  • どんな権限を設定できるか

を、あらかじめ決めています。

つまりGPTに「何でもできる道具」を渡すのではなく、 必要な仕事だけを実行できる道具を用意する考え方です。

DSC Builderでは、さらに、

Plan
↓
人間が確認
↓
Apply
↓
Verify

という流れをつくりました。

まず何を変更するか計画を出す。

私が確認する。

それから実行する。

最後に本物のSharePointから状態を読み直し、 予定と実際が一致したらPASSにする。

ここでは、 AIの自由度を意図的に小さくしています。

AIが走れる道路を先につくり、
その道路の上だけを走らせる。

そんな方法です。

4.Claude in Chrome――AIが既存のサービスへ出かけていく

Claude in Chromeは、 これとはほとんど逆の発想です。

こちらでは、 SharePoint専用APIを私が用意する必要はありません。

自分でSharePointの管理画面へログインする。

その状態で、

「この設定を確認して」

「ここを変更して」

と頼む。

するとClaudeが、 人間と同じように画面を見ながら進みます。

メニューを探す
↓
クリックする
↓
次の画面を開く
↓
入力する
↓
保存する

つまりGPT型が、

サービスをAIへつなぐ

仕組みだとすれば、 Claude in Chromeは、

AI自身が、サービスのところまで出かけていく

仕組みです。

この違いは、 かなり大きいと思います。

APIが用意されていない社内ツールや、 古いシステムや管理画面でも、 ブラウザで操作できるのであれば、 AIが人間と同じ画面を使える可能性があります。

言い換えるなら、

ブラウザそのものを、巨大な共通インターフェースとして使ってしまう

発想です。

5.二つを比較すると、こうなる

比較項目 DSC Builder GPTのようなAPI型 Claude in Chromeのようなブラウザ型
基本思想 サービスをAIへAPIで接続する AIが既存のWebサービスへ行く
操作方法 APIを直接呼び出す 画面を見てクリック・入力する
事前準備 API、認証、スキーマなどの開発が必要 拡張機能を使い、対象サイトへログインすれば始めやすい
開発知識 比較的必要 少なくて済む
操作できる範囲 あらかじめ定義した範囲 ブラウザで到達できる範囲が広い
自由度 低い 高い
実行速度 APIなので比較的速い 画面操作なので相対的に遅い
UI変更の影響 比較的小さい 画面構成変更の影響を受けやすい
APIのないシステム 原則として苦手 強い
同じ処理の反復 得意 可能だが画面状態に左右されやすい
操作範囲の制限 API側で強制しやすい 権限モード、サイト権限、ブラウザ権限などで管理
安全性の考え方 API・権限・処理フロー自体を設計段階で制限 Manual / Auto / Skipから承認・自動チェックのレベルを選択
結果検証 Expected / ActualをAPIで比較しやすい 画面や実行結果を再確認する形になりやすい
監査・ログ operationIdなどで構造化しやすい ブラウザ操作・実行履歴が中心になりやすい
向いている仕事 定型・反復・重要な業務 探索的・臨時・幅広いWeb作業
最大の魅力 確実性と制御 自由度と導入の簡単さ
最大の弱点 作るのが大変 自由である分、監督や安全設定が重要

この表をつくってみると、 単なる「便利さ」の違いではないことが分かります。

システム設計の思想そのものが違う。

のです。

6.Claude in Chromeを先に使ったから、DSC Builderをつくろうと思った

実際の順番としては、 私はDSC Builderより先にClaude in Chromeを試しました。

最初に動かしたときは、 かなり驚きました。

SharePointの管理画面をClaude自身が開き、 設定を探し、 クリックしていく。

私はほとんど見ているだけです。

「これなら、わざわざ専用のアプリをつくらなくてもいいのではないか」

とも思いました。

何しろ、準備が簡単です。

私がSharePointへログインできればいい。

細かな画面操作を全部覚えていなくても、 Claudeが探してくれます。

これは非常に大きなメリットです。

一方、しばらく見ていると、 少し違う面も見えてきました。

目的の場所を探す
↓
クリックする
↓
反応を待つ
↓
違う場所へ行ったら戻る
↓
必要ならもう一度試す

人間がブラウザを操作するのと同じなので、 ときどき少しモタモタします。

セキュリティ確認のポップアップが出れば、 そこで止まることもありました。

さらに初期には、 権限グループを誤って削除してしまったこともありました。

それ以降、

  • 今回は確認だけ
  • まだ変更しない
  • 実行前に確認する

と指示を明確にするようになりました。

この体験から、

毎回同じことをする管理作業なら、
自由に画面を操作させるより、
できる操作を最初から限定した専用の仕組みをつくった方がいいのではないか

と思ったのが、 DSC Builderをつくる一つのきっかけでした。

7.自由度と安全性は、どうしても表裏一体になる

ブラウザ型の最大の魅力は自由度です。

しかし、その自由度は、 そのまま注意すべき点にもなります。

Claude in Chromeは、 ログインしているWebページを直接操作できます。

そのため、ブラウザ型AIでは、 Webページやメールなどの中に埋め込まれた指示をAIが誤って受け取る 「プロンプトインジェクション」のようなリスクも考える必要があります。

Anthropicは、安全分類器や権限制御などの対策を用意していますが、 ブラウザを直接操作する以上、 自由度と安全性のバランスは重要になります。

現在のClaude in Chromeには、 3種類の権限モードが用意されています。

Manual

操作ごとに人間の確認を求めながら進めるモードです。

Auto

Claudeに作業を進めさせつつ、 危険と判断された操作は安全分類器によって自動的にブロックするモードです。

Skip

確認や自動チェックを行わずに進めるモードです。

つまりブラウザ型のAIでも、

どこまで人間が手綱を握るかを、利用者が選ぶ

考え方になっています。

一方、DSC Builderでは、 安全装置の考え方が少し違います。

そもそも危険な操作へ行ける道を用意しない。

別のSharePointサイトは操作できない。

任意のURLは受け付けない。

できる操作も決まっている。

つまり、

ブラウザ型
広い世界を歩けるAIを、どう安全に監督するか

API型
歩ける世界そのものを、最初から狭く設計するか

という違いがあります。

8.「GPTがプラットフォームになる」という未来と、別の未来

ここが今回、 一番面白いと思ったところです。

GPTが登場した2023年には、

ChatGPTの中に、あらゆる専門アプリが集まってくる

ような未来が見えました。

GPT Storeがあり、 専門GPTが並び、 それぞれが外部APIへ接続する。

ユーザーはまずChatGPTへ来て、 そこから必要なサービスを使う。

これは、

AIがプラットフォームになる未来

です。

しかしClaude in Chromeを使ってみると、 まったく別の未来も見えます。

今あるWebサイトや業務システムは、 そのままでいい。

SharePointも、そのまま。

管理画面も、そのまま。

人間向けにつくられた画面を、 AIも操作できるようになればいい。

つまり、

既存のソフトウェアをAI向けにつくり直さなくても、
AIが人間向けの画面を使えばいい。

という未来です。

これはかなり発想が違います。

GPT型
AIのところへ、サービスを持ってくる

Claude in Chrome型
サービスはそのままにして、AIをそこへ送り込む

私は、今回実際に両方を触ったことで、 この違いがとてもはっきり見えました。

9.では、どちらが向いているのか

ここまで比較すると、

「では、結局どちらが正しいのか」

という話になります。

しかし私は、 今のところどちらか一方になるとは思っていません。

むしろ仕事によって分かれるのではないかと思います。

API型が向いている仕事

  • 毎日、毎週、毎月、同じ処理をする
  • 権限や個人情報を扱う
  • 失敗したときの影響が大きい
  • 実行履歴を残したい
  • 同じ結果を安定して繰り返したい

ブラウザ型が向いている仕事

  • 一度しかやらないかもしれない
  • どの画面へ行くか事前に分からない
  • APIが提供されていない
  • 古い管理画面を使わなければならない
  • いろいろなWebサービスを横断したい

今の段階では、

定型業務は専用型。
探索的な仕事はブラウザ型。

という使い分けが、 かなり自然に思えます。

そして将来、 この二つが近づいていく可能性もあります。

最初はブラウザ型AIに自由に仕事をしてもらう。

よく使う仕事が見えてきたら、 それを専用のAPIやワークフローへ落とし込む。

あるいは逆に、 専用APIでは対応できない例外だけをブラウザ型へ渡す。

そんな組み合わせも考えられます。

10.Microsoftの仕組みを一通り使ってみて分かったこと

DSC Builderをつくるために、 今回はMicrosoftのさまざまなサービスを実際に使いました。

  • SharePoint
  • Microsoft Entra ID
  • Azure Functions
  • Azure Key Vault
  • 証明書
  • API
  • OpenAPI

以前から名前は知っていたものもあります。

でも、自分で組み合わせて本当に動かしてみると、 理解の仕方がまったく違います。

「ああ、Entra IDというのは、 AIにこういう身分証を持たせるためにも使えるのか」

「Key Vaultは、 この秘密をここに置くためにあるのか」

「APIというのは、 単にシステム同士をつなぐだけではなく、 AIが安全に仕事をするための“道”にもなるのか」

それまで単なる製品名だったものが、 一つの仕組みとしてつながりました。

もちろん、かなり面倒でした。

動かない。

直す。

また試す。

今度は別のところで止まる。

それでも、 自分がChatGPTへ、

「DSC0007を準備して」

と頼む。

すると、自分でつくった仕組みを通って、 本当にSharePointが動く。

これは、やはり面白い体験でした。

11.「AIが何をできるか」より、「どう仕事を渡すか」

今回、Claude in ChromeとDSC Builder GPTを比べてみて、 AIエージェントについての見方が少し変わりました。

重要なのは、

「AIはどこまで賢くなるのか」

だけではないのだと思います。

むしろ、

私たちはAIへ、どんな形で仕事を渡すのか。

そこが、これから大きなテーマになりそうです。

自由に画面を動かしてもらうのか。

専用のAPIを用意するのか。

どこまで任せるのか。

どこで人間が確認するのか。

手綱を人間が握るのか。

それとも、 手綱そのものをシステムの中へ組み込むのか。

2023年にGPT Storeが発表されたとき、 私は「AIの中にさまざまなアプリが集まる未来」を想像しました。

そして今回Claude in Chromeを使ってみて、

アプリをAIの中へ集めなくても、
AIが今あるアプリを使いに行けばいい。

という、もう一つの未来があることに気づきました。

どちらが主流になるのか。

それとも、 この二つが混ざっていくのか。

今の段階では、 まだ分かりません。

ただ、実際に作ったり使ったりしてみると、

AIエージェントという言葉の中で、
すでにかなり違う未来の形が競い始めている。

そんなことを感じています。

1 2 3 4 5 6 7 8 9 10 ...