記事一覧

2026-09-23 13:31:00

AIエージェントの出発点は、人間が書いた「テキスト」だ

目的と役割を記した指示文、複数のAIの仕事、電力に支えられたサーバーを描いたイラスト

AIエージェントの出発点は、人間が書いた「テキスト」だ

――目的と役割だけでなく、「いつ止まるか」まで決める

「AIエージェントが自律的に動く」と聞くと、 人間から離れた何かが、自分の意思で活動しているように感じます。

しかし、私がつくったエージェントの実態は、 人間が目的と役割を記したテキストです。 そのテキストをAIモデルに渡すところから、仕事が始まります。

1.「あなたは何者か」を、人間が書く

たとえば「この文章を読んで、読者が分からなくなる箇所を挙げてください」と書けば、 AIに読者の役割を与えられます。

「確定した設定と照合し、矛盾した箇所と根拠を示してください」と書けば、 今度は整合性を確認する役割になります。

モデルそのものが、別の生き物に変わるわけではありません。 人間が目的と役割をテキストで定め、AIモデルがそれに沿って仕事をする。 私には、これがエージェントを理解する入口になりました。

一つの仕事にも、いくつもの役割があります。 書く人、調べる人、読む人、矛盾を確かめる人。 それぞれの結果をつなげると、一つの大きな仕事を進められます。

ただし、エージェントの全体がテキストだけでできているわけではありません。 指示を受けるAIモデルがあり、資料を読んだりWebを検索したりする手段があり、 結果を受けて次の作業に進む仕組みがあります。 テキストは、その全体の目的と振る舞いを決める出発点です。[1]

2.「いつ止まるか」も、書かなければならない

ここで、役割の説明だけでは足りないことに気づきました。

「問題がなくなるまで直す」と書いたら、どうなるでしょう。 AIが文章を直し、別のAIが評価し、また修正を求める。 新しい問題を見つけるたびに、作業が続くかもしれません。

「必要な情報を集める」だけでも、どこまで集めれば十分なのか分かりません。 動き出した後に毎回人間の指示を待たないのなら、 終わり方も先に決めておく必要があります。

調べる
↓
書く
↓
評価する
↓
また調べて書き直す
↓
どこで終える?

たとえば、指示文にはこう書けます。 「重大な矛盾がなければ終了する」。 「新しい根拠のない指摘は繰り返さない」。 「判断が分かれたら、人間に返す」。

さらに、文章上の約束だけに任せず、実行するプログラムにも 作業回数や利用量の上限、承認が必要な操作、停止方法を設定します。 テキストが進み方を示し、実行の仕組みが上限を守る。 どちらも人間が設計するものです。[1][2]

何をさせるかを書くのと同じくらい、どこで止めるかを書く。

停止条件を書き忘れた瞬間に、AIがひとりで起動し、永久に動くという意味ではありません。 人間が動かした仕組みの中で、次の仕事が何度も呼ばれ、 予想以上に長く続くリスクの話です。

3.スピードを求めるほど、止め方が重要になる

私たちの社会では、早く調べ、早く作り、早く決めることに大きな価値が置かれます。 人が一つずつ確認するより、AIが次のAIへ仕事を渡した方が速く見えます。

ただ、速い仕組みは、目標を取り違えたときも速く進みます。 調査結果に誤りがあれば、それをもとに別のAIが文章を書き、 さらに別のAIが整った文章として評価するかもしれません。 外部のサービスを操作できるなら、誤った判断が現実の行動にもつながります。[3]

「AIの暴走」には、いろいろな意味があります。 現在のエージェントで具体的に考えたいのは、 人間が決めた目標や停止条件が不十分なまま、与えられた範囲で望まない作業を繰り返すこと です。

複数のエージェントをつないだからといって、 AIモデルが自分自身を再訓練し始めるわけではありません。 目の前で起き得る反復の問題と、将来の能力向上への懸念は、分けて考えたいと思います。

4.小説制作で、終わらないループを経験した

私は長編小説を書く中で、執筆、読者視点、会話、情景、設定の整合性、 事業の現実性などの役割をAIに与えました。

ある一話を6つの担当で同時に評価すると、合計で約82.7万トークン。 ファイルの読み込みは131回。 最も遅い担当が終わるまで、約15分かかりました。

評価が84点になり、文章を直す。 次の版ではある評価が上がり、別の評価が下がって、また84点になる。 設定の一文と本文の台詞が衝突したときは、作者が決めない限り、 AIが何度評価しても結論は出ません。するとループが延々と続きます。

第1版から第9版まで、作者の判断と再評価の往復を含めた経過は2日でした。 大げさな意味での「暴走」ではありません。 でも、何を任せ、いつ人間に戻し、どの条件で完成とするかを 決めていなければ、仕事は予想以上に長くなる。 そのことを、自分の現場で経験しました。

5.AIは、物理資源の上で動いている

この経験で、もう一つ当たり前のことを思い出しました。 AIは文章の中だけに存在するわけではありません。

モデルを動かすサーバー、半導体、メモリ、通信、冷却。 そして、それらを稼働させる電力が必要です。 国際エネルギー機関(IEA)も、AIの利用とデータセンターの電力需要を結びつけて分析しています。[4]

トークンは、AIが扱う文章などを数える単位です。 データセンターに蓄えた燃料ではありません。 私の約82.7万トークンという記録から、電力量を直接計算することもできません。

それでも、計算資源と電力がなければ、AIの処理は続きません。 自律的に見える仕事も、物理的な基盤の上で動いています。

だからといって「電力を止めればよい」で済むわけでもありません。 電力を断てば、AIの処理はそこで止まります。しかし、それまでに評価を繰り返して使った時間や電力は戻りません。私の小説制作でも、どこで人間が判断するかを決めていなかったために、評価と修正が続きました。だから、AIを動かし始める前に「どこまで任せるか」「いつ人間に戻すか」を決めておく必要があります。

6.「何をさせるか」と「どこで止めるか」

エージェントの出発点は、人間が書いたテキストです。 そこに目的と役割を書く。 そのテキストが、AIモデル、道具、計算資源と結びついて、仕事として動き出します。

私は今、エージェントへの指示を考えるとき、 「何をしてほしいか」と一緒に、 「どこまで任せるか」「何を人間に返すか」「いつ終えるか」を考えるようになりました。

AIを速く動かすためのテキストに、止まるための条件も書く。
その条件を、実際に動かす仕組みでも守る。

目的を書くのも、止め方を決めるのも、人間です。 AIエージェントを使うとき、私たちの手元に残しておきたい設計は、 そこにあると思います。

参考資料

  1. OpenAI, OpenAI Agents SDK/Running agents(指示文、道具、反復処理、実行上限)
  2. Anthropic, Building Effective AI Agents(停止条件と人間の判断を含む設計)
  3. Anthropic, Trustworthy agents in practice(権限と人間による制御)
  4. IEA, Energy and AI(データセンターの電力需要)

※制作時の数値は筆者の実行記録によります。トークン数は6つの評価担当の合計であり、 消費電力量や同時実行の所要時間を示す数値ではありません。

2026-09-22 15:53:00

千代田区の土砂災害警戒区域を、AIエージェントと2往復でつくった話

――AIエージェントと、地図9枚を配れる資料に変えるまで

昨日、区内の土砂災害警戒区域を伝える資料を、AIエージェントと一緒につくりました。 「重ねるハザードマップ」からキャプチャした地図画像9枚を渡してから、 配布できる形に整うまで、思っていたよりずっとスムーズに進みました。

災害対応の時、AIがWeb等の制作でとても役に立った記録として、その過程を残しておきます。

つくったもの

区内9か所の地図を、配布できる14枚の資料に
  1. 制度の説明(警戒区域と特別警戒区域の違い)
  2. 9エリアの一覧と、各ページへのジャンプリンク
  3. エリアごとの地図とGoogleマップへのリンク
  4. 出典の明記
  5. 大雨時の心構え

渡したのは、区内9か所の地図画像だけでした。

AIに任せたこと、自分で決めたこと

最初に渡したのは、地図画像と「出典を明記してPowerPointにしたい」という一文だけでした。 そこから先を、どこまでAIに任せ、どこから自分で決めたのかを分けてみます。

AIに任せたこと 自分で決めたこと
  • 資料全体の構成(表紙→制度説明→目次→エリア別ページ→備え→出典)
  • 配色・レイアウトなどのデザイン
  • 出典の正確な書き方(国土交通省・国土地理院の記載ルールを調べて反映)
  • 各エリアの場所を特定し、Googleマップへのリンクを個別に用意すること
  • タイトルの言葉づかい
  • 最終ページに何を載せるか(問い合わせ先ではなく区のホームページ案内にする)
  • 制作主体をDSC名義にすること
  • 特定のページだけリンク先を大学名に変えること
AIは選択肢を形にしてくれます。でも、何を選ぶかは人の仕事だと、あらためて感じました。

進め方

地図9枚と依頼を渡す
↓
初稿が返ってくる
↓
気になった点をまとめて伝える
↓
反映を確認する
↓
1か所だけ指定し直す

依頼から配布できる形になるまで、往復はわずか2回でした。 細かい指示を一度にまとめて出したのが、よかったのかもしれません。

感じたこと

一番助かったのは、出典表記のルールまでAIが自律的に調べて正しく反映してくれたことでした。 地図や統計を扱う資料は、出典の書き方ひとつで信頼性が変わります。 そこを都度自分で確認せずに済んだのは、時間に追われる中で災害対応をまとめる際に想像していた以上に助かりました。

後から気づいた修正点(制作主体の変更やリンク追加)は、当然ながら最初の依頼には書いていませんでした。 任せる時点ですべてを見通して指示を出す必要はなく、出てきたものを見てから直す―― という進め方でも十分にスムーズだった、というのが今回の実感です。

配布資料

今回作成した資料は、こちらからご覧いただけます。

pdf 千代田区土砂災害警戒区域 (6.81MB)

2026-09-21 17:55:00

千代田区内で公開されている防災・観光・街並みのライブカメラ

――区内で公開されている防災・観光・街並みのライブカメラをまとめる

千代田区内で一般公開されているライブカメラを調べ、一つの一覧にまとめました。区・都が運営する防災用のカメラから、神社仏閣の公式カメラ、街並みを映す個人・団体のYouTube配信まで、性格の異なるカメラが数多く公開されています。

2026年9月時点で確認できたものを、目的別に3つに分けて掲載します。

地図で見る

各カメラのおおよその位置を番号入りのピンで示しています。ピン(または下の表のリンク)をクリックすると配信ページが開きます。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 北 ↑

背景地図:国土地理院(淡色地図)。カメラの案内番号を重ねて表示しています。

区・都の公式カメラ(防災)観光・神社仏閣街並み・交通

※ 番号は名称に基づくおおよその案内位置で、カメラの正確な設置位置・撮影方向を示すものではありません。近接する番号は引出線で配置しています。スマートフォンでは地図を左右にスクロールできます。

区・都の公式カメラ(防災)

千代田区と東京都が、水防・防災の目的で運用しているカメラです。区役所屋上の高所カメラのほか、神田川・日本橋川を映す河川監視カメラが公開されています。

No.名称概要リンク
1千代田区役所 高所カメラ区役所本庁舎屋上の鉄塔に設置された2台のカメラ(北東方向・西方向)。区内全域を見渡せる、区公式の防災用カメラです。見る
2後楽橋(神田川)千代田区が独自に運用する河川情報システムの映像地点の一つ。神田川の水位状況を確認できます。見る
3三崎橋(日本橋川)同じく区の河川情報システムの映像地点。日本橋川の状況を確認できます。見る
4神田川・飯田橋 河川監視カメラ東京都建設局が設置する河川監視カメラの一つ。「水防災総合情報システム」とYouTube「水防チャンネル」で24時間配信されています。見る

観光・神社仏閣

観光協会や神社が独自に運営しているカメラです。季節限定のものや常設のものが混在します。

No.名称概要リンク
5千鳥ヶ淵ライブカメラ千代田区観光協会が運営。千鳥ヶ淵ボート場屋上に設置され、「千代田のさくらまつり」期間中(例年3月下旬〜4月上旬)のみ桜の様子を配信します。見る
6神田明神 公式ライブカメラ神社公式サイトが常設するライブカメラです。見る
7靖国神社境内の様子を映すYouTube配信。夜間は配信を停止します。見る

街並み・交通

個人・団体が設置しているYouTube配信を中心に、区内各所の街並みや交差点を映すカメラです。

No.名称概要リンク
8神田駅北口交差点中央通りの交差点を映すYouTubeライブ配信。見る
9秋葉原駅付近(中央通り)秋葉原駅周辺の中央通りを映すライブカメラ。見る
10秋葉原 中央通り交差点中央通りの交差点を映すYouTube配信。見る
11秋葉原 中央通り別チャンネルによる中央通りのYouTube配信。見る
12秋葉原駅北側秋葉原駅北側の様子を映すYouTube配信。見る
13東京駅(日テレ)日本テレビによる東京駅を映すYouTube配信。見る
14東京駅丸の内口エリア丸の内駅舎(赤レンガ駅舎)周辺を映すYouTube配信。見る
15東京駅(有楽町カーブ)新幹線・在来線が走る有楽町カーブ付近を映すYouTube配信。見る
16東京駅八重洲口 タクシー乗り場東京タクシーセンターが提供する、八重洲口タクシー乗り場の待機状況カメラ。見る
17霞が関官庁街の街並みを映すYouTube配信。見る
18千代田区内幸町内幸町一帯の街並みを映すYouTube配信。見る
19弁慶橋ボート場弁慶濠(外濠)を映すYouTube配信。見る
20首都高 竹橋JCT付近首都高速都心環状線・竹橋JCT付近を映すYouTube配信。見る
21千代田区麹町(新宿通り)新宿通り沿いの麹町を映すYouTube配信。見る
22外神田ライブカメラウェザーニュース「Myライブカメラ企画」による個人設置カメラ。気温・天気データ付きで配信されています。見る
千代田区内には、区・都が運営する防災用カメラから、神社仏閣の公式カメラ、街並みを映す個人配信まで、性格の異なるライブカメラが数多く公開されています。

出典

  1. 千代田区河川情報システム(chiyoda-kasen.tenki.ne.jp)
  2. 千代田区ホームページ「高所カメラ」(city.chiyoda.lg.jp)
  3. カメ探「千代田区のライブカメラ」(cametan.com)
  4. ウェザーニュース「千代田区外神田のライブカメラ」(weathernews.jp)
  5. 東京都オープンデータカタログサイト「河川監視カメラ位置情報データ」(東京都建設局)

※ 掲載情報は2026年9月時点で確認できたものです。配信の有無・URL・配信時間帯は変更される場合がありますので、最新の状況は各リンク先でご確認ください。

2026-09-16 22:00:00

AIに任せる仕組みを作って、最後に残った時間 — 「文明の夜明け」の先で考えること

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

――任せられるようになったあと、自分はどこに関わりたいか

AIに任せる仕組みを作って、最後に残った時間 — 「文明の夜明け」の先で考えること

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

前回の 「AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ」 では、執筆担当AIエージェントが書いた原稿を、複数の評価担当AIエージェントが読み、 その指摘を次の改稿へつなぐ仕組みを紹介しました。

作品の目的や人物を設定ファイルに書き、読む順番や役割分担をハーネスとして整え、 評価と改稿のループを回す。一年間、小説を書くために取り組んできたことです。

仕組みが動くようになったとき、私は、このやり方に納得しました。 毎回の指示だけで長い物語を書き続けてもらうより、判断の根拠と仕事の手順を残しておく。 それを複数のAIエージェントが参照しながら、原稿を受け渡していく。 自分が目指していた制作の形が、かなり見えてきました。

同時に、ひとつのことに気づきました。

この仕組みで、いちばん時間がかかるのは、
私が読むところなのではないか。

最終回は、設定ファイルの外に残った、この時間について考えます。

1.任せられるようになって、自分が止めていると分かった

原稿を作る速さと、読む速さ

AIエージェントは、設定を読み、原稿を書き、評価をまとめます。 私が改稿を依頼すると、指摘を踏まえた次の版が作られます。

もちろん、設定と食い違うこともあります。評価が高くても、自分にはしっくりこない文章もあります。 それでも、原稿を作り直す速度は、私が一つひとつ読んで考える速度を上回ります。

制作工程だけを見れば、私はボトルネックです。

原稿ができても、私が読まなければ先へ進めません。 どの指摘を受け入れるか。直したことで、人物の言葉が自然になったか。 この文章を、自分の作品として送り出したいか。そこで時間がかかります。

仕組みを整える前は、どうすればAIに書き続けてもらえるかを考えていました。 書き続けられるようになると、今度は、自分がどこで止めているのかが見えてきました。

小説では、その時間を残したかった

ただ、小説では、その時間をなくしたいとは思いませんでした。

自分が読んで面白いと思うことも、私が小説を書く理由だからです。 ルミや莉子が何を言い、何を言わなかったのか。その場面を読み、自分の中に何が残るのか。 それを確かめる時間まで省いてしまったら、私にとっての創作の楽しみも減ってしまいます。

評価の点数は参考になります。 でも、点数を見ただけでは、自分がその小説を読んだことにはなりません。

読者が面白いと感じるかどうかは、一人ひとりに委ねるしかありません。 その前に、私自身が読んで、この作品を送り出そうと思えるか。その判断は残しておきたいのです。

工程を速くするうえでは待ち時間でも、私にとっては、作品に関わるための時間でした。

2.サイト制作では、違う場所で確かめていた

「文明の夜明け」を感じた体験

小説と並行して、Digital Supporters Clubの会員制クラブサイトも作っています。 その過程で経験したことを、 「ものづくりの時間が変わった――『文明の夜明け』を感じた」 という記事に書きました。

会員ごとのフォルダ作成や権限設定を支援する、小さな管理ツールの開発です。

AIはコードを書くだけでなく、そのコードを確かめるテストも作り、実行しました。 問題があれば修正し、またテストする。 テストに使う模擬的なSharePointの環境まで、コードとして用意していました。

作る、試す、直す、もう一度試す。

この一連の作業が、自分の知っていたシステム開発とは違う速度で進んでいきました。

私はプログラムを一行も書いていません。 それでも、自分が必要としている道具が形になり、動作を確かめるところまで進んでいく。 その様子を目の前にして、文明の夜明けを感じました。

コードを全部読む代わりに、動かして確かめる

このとき、私は生成されたコードをすべて読むことはしませんでした。

設計書には目を通しました。自分が頼んだ内容になっているかを確認し、実際の環境で動かしました。 しかし、小説の原稿を読むときのように、一行ずつ表現を味わう読み方ではありません。

小説では、文章そのものを読みたい。 管理ツールでは、必要な仕事が意図したとおりに行われるかを確かめたい。

同じ私でも、何を作るかによって、判断を入れる場所が違っていました。

コードを全部読む工程を通らなくても、開発は進みます。そのぶん、AIが書いて試す速さを生かせます。 ただ、AIによるテストが通っても、実際に使う環境で動くかどうかは、別に確かめる必要がありました。

テストの中では合っていても、現実とは違った

実際、AIが用意したテストを通過したあと、本物の日本語版SharePointで問題が見つかりました。

コードは、権限の名前が英語で返ってくる前提で作られていました。テスト用の模擬環境も、同じ前提でした。 両方が英語の名前を使うので、テストは通ります。

ところが、本物の環境からは日本語の表示名が返ってきました。

コードとテストが一致していることと、
現実に合っていることは違っていたのです。

私は実行結果をAIへ返しました。AIは表示言語に左右されない方法へコードを修正し、テストも追加しました。

ここで私が行ったのは、コードを自分の手で直すことではありません。 実際に使う環境で確かめ、見つかった違いを制作の工程へ戻すことでした。

この経験は、小説を書く仕組みにもつながります。 原稿と設定が一致しているかは確認できます。 しかし、それを読んで何を感じるかは、実際に読んでみなければ分かりません。

3.速さを受け入れながら、どこに関わるかを決める

人間の判断を待たない工程は増えていく

この二つの経験から、私は、人間が途中で判断する機会は、 仕事によってはこれからも減っていくと思うようになりました。

一つの作業が終わるたびに人が読み、確認し、次へ進む許可を出す。 その時間を省ければ、成果物ができるまでの時間は短くなります。 速さが経済的な価値を持つ環境では、確認を自動化できないか、まとめて行えないかと考えるのは自然です。

対象を限った作業であれば、依頼してから成果物ができるまで、 一度も人が判断を挟まない形も増えていくでしょう。

私は、それ自体を悪いことだとは考えていません。

何度も繰り返す処理や、結果を機械的に確かめられる作業まで、必ず人が待ち構えている必要はないからです。 一方で、人の確認を外したからといって、品質が自動的に上がるわけでもありません。 SharePointの経験では、コードとテストに共通する前提が、現実と食い違っていました。

自分の設定ファイルにも、確かめていない根拠があった

小説の調査記録でも、同じような問題に向き合いました。 AIが調べた情報をファイルに残し、執筆や評価の根拠にしていましたが、 出典のURLがあるだけでは、原典を直接読んで確かめたのか、 要約や解説を経由したのかが分かりません。

そこで、調査記録の一行ごとに確度ラベルを付けました。 どこまで確かめたかを、四段階で残します。

ラベル どこまで確かめたか 本文での扱い
A 法令や公的機関の一次資料を、原典で直接確認した 数字や条文の断定に使える
B 公的機関の情報だが、要約や解説を経由している 事実の方向は使える。数字はAへ上げてから出す
C 二次情報(解説記事、事業者の見解、まとめ記事) 本文で断定に使わない
D 未確認 本文で断定しない

数字を本文へ出すときは、その行がAであることを確認します。 BやCであれば、先に原典へ当たってAへ上げてから使います。

2026年9月6日の導入時、その日に追加した調査記録には、Aの行が一つもありませんでした。 これは、記録がすべて誤りだったという意味ではありません。 原典で直接確かめたと言える行が、まだなかったのです。

本文と調査記録を照合して一致していても、調査記録そのものの根拠が確かとは限りません。 ラベルを付けても、それだけで正しくなるわけではありません。原典に戻って確認する作業が必要です。

コードとテストの照合にも、本文と調査記録の照合にも、共通する限界がありました。
同じ前提を共有したもの同士を比べるだけでは、その前提の誤りを見逃すことがあるのです。

脅威という言葉だけでは、付き合い方は決まらない

文章、プログラム、設計書、画像。 AIが作ったり、制作に関わったりするものは、身の回りで増えていくと思います。 公開されたインターネットの情報だけでなく、仕事で使う資料や、自分だけが使う道具にも、 その変化は広がるでしょう。

私は、その変化を脅威という言葉だけで捉えたくありません。

自分ではコードを書かなかった私が、必要な道具を作る工程に参加できました。 長い物語を作るために、複数のAIエージェントと原稿を受け渡すこともできるようになりました。 できることが増えた実感があります。

AIが文章やプログラムを作ることは、これから当たり前になっていくと思います。 その変化を受け入れ、AIに何を任せ、自分はどこに関わるのかを、暮らしや仕事の中で考えていきたいのです。

すべての工程を自分の手で行わなくてもいい。 途中の成果物をすべて読む必要も、仕事によってはないでしょう。 そのうえで、出来上がったものを誰が使うのか。実際に役に立っているのか。 問題が起きたときに、どこへ戻ればよいのか。

制作を速く進める仕組みと、その成果を実際に使って確かめる機会を、両方持っておきたいと思います。

経営に置き換えると

人がすべての成果物を確認することを前提にすると、AIが作る速度に確認が追いつかなくなるかもしれません。 そこで必要になるのは、業務ごとに、人が判断する場所を具体的に決めることだと思います。

社内で比較するための案なのか。顧客へそのまま送る文章なのか。 実行すれば権限や契約条件が変わる処理なのか。 同じ「AIが作ったもの」でも、確かめるべきことは違います。

今回の管理ツールでも、まず新しい会員一人の利用準備に範囲を絞りました。 実際に試し、運営が楽になるかを確かめるところから始めました。

任せる範囲を決め、結果を確かめ、その結果に応じて範囲を変える。 この判断まで含めて、AIと働く環境を作ることなのだと思います。

最後に残したい時間

第2回は、 「AIに長編小説を書かせ続けるために、設定ファイルを16個に分けた話」 でした。

その設定の置き場を今回あらためて数えると、直下に24ファイルと、 調査記録と作中の観測値を収める2つのフォルダがありました。 24ファイルの内訳は、番号の付いた22ファイルと、人物の確認用ファイル、文体の憲法です。 フォルダ内の記録は、この数には含めていません。

第2回のタイトルに置いた数字は、制作を続ける間に変わりました。

ファイルが増えたから、質が上がったとは言えません。 調査記録がそろっていても、原典の確認が足りていないことはありました。 書き残すべきことや、確かめるべきことが変わり、そのたびに構成を見直してきた結果です。

この連載では、設定ファイルの質を、別の日の自分と、担当の違うAIが、 同じ判断に行き着けることとして考えてきました。

作品の目的、人物の願い、文体、時系列。 それらを書き残し、AIエージェントが使える手順に組み込みました。 評価の観点を分け、指摘を改稿へ戻す流れも作りました。

その仕組みは、これからも変わるでしょう。 任せられることが増えれば、今は私が行っている確認を、AIに任せることもあると思います。

それでも、小説を読む時間は残したい。

AIエージェントが原稿を作る速さに、私が読んで考える速さは追いつきません。 でも、自分が読んで面白いと思うことも、私が小説を書く理由だからです。

サイト制作で感じた「文明の夜明け」は、ものを作る工程が、 自分の知っている速さを超えて動き始めた実感でした。 小説制作では、その速さの中で、自分が残したい時間に気づきました。

設定ファイルも、ハーネスも、評価と改稿のループも、AIに任せるために作りました。 その仕組みが動くようになったことで、今度は、自分がどこに関わりたいのかが見えてきました。

すべてを自分で作ることにこだわらなくなっても、 自分が何に価値を感じるのかは、問い続けていたいと思います。

「自分はどこに関わりたいか」という問いには、対応する一つの設定ファイルはありません。 仕組みを使いながら、私自身が考え続けることです。

前回: AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ

次回: 全8回の連載は、今回で終わりです。

2026-09-16 00:00:00

AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ

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

――設定を誰に、どの条件で使わせ、評価後にどう改稿するか

AIに小説を書いてもらう手順を設計する — ハーネスと、書き直すループ

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

前回の 「時系列と確定事実 — 矛盾はここで起きる」 では、過去の出来事を記録し、次の場面と照合する工夫を紹介しました。 今回は、それらをどう組み合わせてAIに使ってもらうかという話です。

これまで、作品の目的、文体、人物、タイムライン、用語集について書いてきました。 ほかにも、各回で何を描くかを決めた場面設計があります。

必要な設定をそろえても、AIが適切に参照し、作品に反映するとは限りません。 何を読んでから書くのか。設定が食い違ったら何を優先するのか。 書いた本文を誰が確かめ、どこへ戻して直すのか。 その手順も設計する必要があります。

第1回「AIが働く環境をつくった一年」 では、AIと制作する仕組みを四つの層で整理しました。 今回は、そのうちの「Harness Engineering — AIが働く『環境』を設計する」と 「Loop Engineering — 生成・評価・修正の『反復』を設計する」を、実際の執筆工程から紹介します。 以下では、それぞれを短く「ハーネス」「ループ」と呼びます。

これまで整えてきた設定ファイルを、どの担当AIエージェントに、どの条件で使わせるか。 そして、評価で見つかった問題を、どう次の改稿へ戻すか。 問い50までの制作記録をもとに、そのつながりを見ていきます。

1.設定ファイルを、執筆の手順につなぐ

「何を渡すか」の次に、「どう使うか」を決める

人物設定には、その人が何を願っているかを書きます。 タイムラインには、いつ何が起きたかを残します。 場面設計には、その回で起こす出来事や、中心となる場面を記します。

それぞれ役割が違うので、AIにまとめて渡すだけでは、どの情報を何の判断に使うかが曖昧になります。

そこで、執筆担当AIエージェントには、その回に関係する設定を読み直してから書くよう指示しています。

日付や小道具の状態は、以前のチャットで伝えたから覚えているはず、と考えず、 執筆のたびに設定ファイルを読み直して確認させます。

読む順序と、判断の優先順位も分けて考えます。 後から読んだファイルが、そのまま優先されるわけではありません。 記述が食い違った場合は、あらかじめ定めた優先順位へ戻ります。

何を読むかに加えて、読んだ情報をどう扱うかまで決める。
これが、小説を書くためのハーネスの中心です。

入口になる二つのファイル

この運用を記述しているのが、AGENTS.mdとCLAUDE.mdです。

制作を始めるときの入口として、依頼の受け取り方、執筆から評価へ進む手順、保存方法、 改稿や承認の扱いを伝えます。 ファイル自体がプログラムを実行するのではなく、AIが作業するときに従う指示書です。

二つのファイルは、使う環境に応じて参照される入口として用意し、同じ運用内容を保つ方針にしています。

たとえば、AGENTS.mdには、次のような依頼の読み分けがあります。

私が入力すること AIに行わせること
Q44を書いてください 執筆し、各担当AIエージェントが評価し、結果を統合する
Q44を本文だけ書いてください 本文の執筆だけを行う
Q44を書き直してください 最新稿と評価レポートを読み、改稿して再評価する
Q44を承認してください 確定稿を保存し、タイムラインと用語集を更新する

「書いてください」という短い依頼の後ろに、必要な作業をあらかじめ置いておきます。 毎回、同じ長い指示をチャットに書かなくても、何をどこまで行うかが決まります。

場面設計を、均等に文章化しない

場面設計に書かれたことを、順番にすべて文章にすれば小説になるわけではありません。

そこで、執筆担当AIエージェントには、本文を書く前に、必ず入れる出来事、表現の候補、禁止事項、 核となる場面、短く処理する場面、分量を取り出すよう指示しています。

必ず入れる出来事と、使ってもよい表現の候補を分ける。 中心となる場面に分量を寄せる。すべての出来事を同じ長さで並べない。

問い50では、二人が答案を広げ、一緒に分からない問題を調べる場面を書きました。 その後、勉強の場面を約250字短くした版を作っています。

再評価では、会話の奥行きを見る担当AIエージェントが、短くしても 「二人とも分からない問題を一緒に調べる」という場面の働きは保たれていると確認しました。

大切なのは、勉強の手順を残らず書くことではありません。 片方が教え、片方が教わるだけの関係にならず、二人が一緒に取り組んでいることです。

こうした場面の核を、執筆時にも改稿時にも確かめられるようにします。

2.四つの視点で読み、それぞれの問題を見つける

同じ本文を、違う観点から読む

本文ができたら、執筆担当AIエージェントの自己確認を経て、評価へ進みます。

問い50までの基本となる評価は、四つの観点に分けています。それぞれに別の指示文があります。

担当AIエージェント 主に見ること
創造性の担当AIエージェント 人物が動いているか、場面に引っかかりや余白があるか
読者視点の担当AIエージェント 本文だけで理解でき、続きを読みたくなるか
会話の奥行きの担当AIエージェント 本音と建前のずれや、言わないことが働いているか
情景と感情の担当AIエージェント 場所や身体の描写から、感情を受け取れるか

実際に問い50のv3では、評価する場所が分かれました。

読者視点の担当AIエージェントは、前の回を読んでいないと一瞬分かりにくい言い回しを指摘しています。 一方、情景と感情の担当AIエージェントは、6月という時期が日付の情報にとどまり、 湿度などの体感が弱いと指摘しました。

会話の奥行きの担当AIエージェントは、莉子が保管していた絵について言う 「捨てる理由ないし」という台詞を評価しています。 保管していた理由を説明せず、言葉の表面と、その下に読めるもののずれを残しているからです。

同じ原稿でも、読む入口が違えば、拾うものが変わります。 評価を分けることで、何を残し、何を検討するかが具体的になります。

読者役には、設定を渡さない

役割を分けるときには、渡す情報も変えています。

読者視点の担当AIエージェントには、設定ファイルや場面設計、ほかの評価レポートを渡しません。 今回の本文だけを読ませます。

設定を知っていれば、本文に書かれていない理由を補えてしまいます。 作者の意図を知っているから理解できたのか、本文だけで理解できたのかが分からなくなるためです。

問い50の評価で「前の回を読んでいないと分かりにくい」と指摘できることも、この読み方に意味がある理由です。 その指摘を受けて、説明を足すか、連続して読む作品として残すかを検討できます。

一方、整合性を確認する担当AIエージェントには、設定と確定稿を読み直させます。

問い50には、莉子の「真帆方式」に、ルミが「真帆さん方式」と返す短いやり取りがあります。 会話としては、姉を呼ぶ妹と、憧れている相手を呼ぶルミの違いが出ています。

同時に、整合性の確認では、ルミがすでにその名前を知っているかを確かめる必要があります。 問い47で命名が成立しているため、問い50で使える呼び名です。

言葉の面白さを読むことと、その言葉を使える時点かを確かめること。
両方が必要なので、担当AIエージェントと渡す情報を分けています。

複数の指摘を、改稿する箇所へまとめる

問い44の初稿では、ルミが不満をぶつける長い台詞に、複数の担当AIエージェントが注目しました。

創造性、読者視点、会話の奥行きの評価が共通して指摘したのは、 不満が経緯どおりに並び、報告のように整いすぎていることでした。

整合性の担当AIエージェントは、同じ台詞の「仕事くださいって」という言い方が、 問い42での実際の発言と少し違うことを指摘しています。

統合担当AIエージェントは、これらを同じ箇所の改善提案としてまとめました。

次の版では、台詞が途中で切れる形になっています。

「お姉さんも。弟子にしてって言ったら、募集してないって。お父さんは、信じるんだ、って。信じて、どう――」

再評価では、長台詞の整いすぎと、過去の発言との微差が解消されたことを確認しています。

「もっと自然な会話にする」という依頼だけでは、何を変えるかが曖昧です。 誰がどこを問題にしたかをまとめ、次の原稿で直す箇所へつなげます。

3.評価を、次の改稿へ戻す

ループの指示は、どこにあるのか

評価が終わると、統合担当AIエージェントが各レポートを読み、総合点と改善提案をまとめます。 その指示文が、99_integrated_analyzer.txtです。

点数の計算方法だけでなく、優先して直す箇所、修正の大きさ、次にどの評価を行うかも定めています。

一方、改稿を依頼されたときに、どの原稿とレポートを読み、どこまで実行するかは、 AGENTS.mdとCLAUDE.mdに書いてあります。

ループは、一つの専用ファイルにまとまっているわけではありません。 運用ファイルが改稿の進め方を定め、統合担当AIエージェントの指示文が評価結果を次の修正へつなぎます。

設定を確認する → 本文を書く → 各担当AIエージェントが評価する
→ 結果を統合する → 改稿を依頼する → 次の版を書き、再評価する

現行の基本コマンドでは、「書き直してください」と依頼すると、改善提案を反映し、評価と統合まで一巡します。 「優先度1だけ反映してください」と指定した場合は、その範囲を直し、再評価は明示して頼む扱いです。

どこを直すか、どこまで評価を回すかを指定できるようにしています。

原稿と評価を、同じ版で残す

ループを回すには、評価がどの原稿に対するものかを間違えないことも必要です。

原稿はq44_v1.md、次の版はq44_v2.mdというように保存し、 評価レポートにも同じ版番号を付けます。原稿は上書きしません。

問い44では、長台詞の問題が解消された後のv2でも、別の指摘が残っていました。

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

この一文を、読者より先に地の文が答えを採点していると最初に指摘したのは、v2の評価です。 v4でも指摘され、確定稿で削除しました。

版を残していれば、何がいつ指摘され、いつ直ったかを確かめられます。 「評価されて直した」という一つの話にまとめず、 どの原稿に対する評価だったかをたどれるようにしています。

点数は、改稿の良し悪しを一つで表せない

総合点は、原稿の状態を確認する目安になります。承認基準の一つは85点以上です。 ただし、必要な評価がそろい、重大な矛盾や規則違反がないことなど、ほかの条件も満たす必要があります。

問い50では、勉強の場面を約250字短くしたところ、総合点はv2の90点からv3の88点になりました。

一方、v3のレポートでは、創造性と情景の担当AIエージェントが、中盤のもたつきが解消したと評価しています。 会話の奥行きの担当AIエージェントも、二人が一緒に取り組む場面の働きが保たれたと確認しました。

レポートには、評価が別のセッションで行われたため、数点の揺れを含むという注記もあります。 この記録から、短くしたことが点数を下げた原因だとは言えません。

点数だけなら、前の版へ戻したくなるかもしれません。 しかし、何を直そうとして、本文がどう変わり、各評価が何を確認したかまで読むと、判断する材料は変わります。

問い44でも、総合88点の稿に残っていた地の文の指摘三箇所に対し、 確定稿では二つを削除し、一つを残しています。

ループの目的は、評価の指摘をすべて消すことではありません。
作品に必要な表現を残しながら、問題を直すことです。

止める条件と、次へ渡す条件を決める

整合性を確認する担当AIエージェントが重大な矛盾を見つけた場合は、 ほかの評価が高くても承認不可にします。 面白さの点数で、事実の食い違いを埋め合わせないためです。

後半の制作では、本文の現実性を見る担当AIエージェントと、 執筆前に調査記録の根拠の確かめ方を検査する担当AIエージェントも加えました。 進める手順と同じように、止める条件も必要になったからです。

そして、承認するときには、本文を確定するだけでなく、次の回へ渡す記録も更新します。

問い47では、莉子からのLINEで『真帆』という名前が伝わります。 それまで「お姉さん」だった人の名前を、ルミが知る場面です。

評価レポートは、本文を承認できる水準としつつ、命名などを設定へ反映する必要も挙げています。 用語集には、問い47で名前が伝わったことが記録されています。 その記録が、問い50の「真帆さん方式」という台詞を支えます。

今回の本文で起きたことが、次の回の前提になる。 前回紹介した記録の仕組みも、ここで執筆の流れにつながります。

経営に置き換えると

業務でも、AIに資料を渡して「提案書を作って」と頼むだけでは、 何を根拠に書き、誰に確認してもらうかが曖昧になります。

提案書なら、顧客の要望、社内の商品情報、承認済みの価格を参照させる。 作成後は、顧客に伝わるかを読む担当AIエージェントと、価格や提供条件を照合する担当AIエージェントを分ける。 未承認の条件が含まれていたら、提出前に止める。こうした手順が、ハーネスにあたります。

確認で見つかった問題をまとめ、修正した版を作り、直した箇所を再確認する。その反復がループです。 提案書と確認結果に同じ版番号を付けておけば、 古い価格を直したのか、前の版への指摘が残っているだけなのかも区別できます。

小説の制作で設計してきたのも、同じことです。 何を参照するか、何を確かめるか、どの条件で止めるか、修正をどこへ戻すか。 AIに任せる仕事を、この単位まで具体的にしておきます。

設定ファイルに、作品の判断基準を書く。 ハーネスで、その基準を誰がどの場面で使うかを決める。 ループで、評価を本文の修正へ戻す。

小説を書くうえで私が大切だと感じているのは、このつながりです。 設定を詳しく書くだけでなく、その設定が執筆と評価のどこで働くかまで設計しておきます。

次回は、全8回の最終回です。 仕組みが動くようになったあとに残った、私自身の時間について考えます。

関連する運用ファイルと指示文

AGENTS.md/CLAUDE.md

制作の入口となる運用指示です。 依頼の解釈、執筆・評価・改稿の流れ、版の保存、承認、失敗時に止める条件を定めます。

00_priority.md

設定が食い違った場合に、どの指定を優先するかを定めます。

1_writer_agent_extended_v2.txt

執筆担当AIエージェントへの指示文です。 執筆前に参照する設定、場面設計から取り出す項目、本文を出す前の確認などを定めます。

2_creative_evaluator.txt/3_reader_validator.txt/4_dialogue_complexity_evaluator.txt/5_landscape_emotion_evaluator.txt

基本となる四つの評価担当AIエージェントの指示文です。観点と、必要な入力を分けています。

7_consistency_validator.txt/8_simulation_reality_evaluator.txt/9_research_integrity_validator.txt

それぞれ、設定と本文の整合性、本文の現実性、執筆前の調査記録の根拠の確かめ方を検査します。

99_integrated_analyzer.txt

評価を統合し、総合点、優先度別の改善提案、合否判定、再評価の対象をまとめるための指示文です。

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