TL;DR: さくらのAI Engineで動かしているAI小説執筆エンジンに、登場人物や伏線を構造化して持つ「ナレッジグラフ」を新設し、AIが自分の判断で検索できるツールとして実装した。実装自体は正しく動いた(セッション内で確認した範囲では、テストも全件パスした)。しかし、実際に章を1本書かせてみたところ、そのツールが呼ばれた回数は0回だった。今回の観測だけで確定的には言えないが、最も有力な仮説として見えてきたのは、「ナレッジグラフ」という発想ではなく、検索インターフェースだけを先に作り、データを入れる仕組みを後回しにした実装の順番のほうに無駄があった、ということだった。
前回までのおさらい
複数のさくらのAIモデルが合議制で異世界転生小説を毎日書き続け、消費リクエスト数がそのまま物語の進行度になる——「さくらAIで転生小説を書いてみる」シリーズの第5回。
第1〜3回で企画・世界観・キャラクター・章立てを固め、執筆エンジンを実装して第1章を生成した(校正担当AIのコード混入バグを発見し除外)。第4回では、第2章生成中に「AI全滅」に見える障害が発生し、実は.env未読み込みとコンテキスト長上限という別々の2つのバグだったことが分かった。語り担当を「2候補生成+AI裁定」方式に再設計し、無事に第2章が完成した。
まず結論から
このエンジンはこれまで、さくらのAI Engine上の複数モデルが役割分担して1つの異世界小説を書き続けている。前章までの過程で、このエンジンが使っている既存のRAG検索(全文をベクトル化して類似度で引っ張ってくる仕組み)には限界があると分かっていた。この実装のRAGは既存の文脈に「上乗せ」する仕組みであり、AIが「この登場人物の現在の状態」のような特定の事実だけを狙って取り出す手段にはなっていなかった。
そこで、事実を構造化して蓄積する「ナレッジグラフ」を新設し、整合性チェック担当のAIが自分の判断で検索ツールを呼び出せるようにした。まずは空のグラフから始め、ツール呼び出しの仕組みそのものが正しく動くかどうかだけを確認するつもりだった——この「つもりだった」が、今回のすべてを言い表している。
新規モジュール2本を追加し、AIモデルへツールのスキーマを渡すところまで動作確認できた。だが、実際に章を1本生成させてみたところ、整合性チェック担当のAIは、このツールを一度も呼ばなかった。「動く」ことは確認できたが、「使われる」ことは確認できなかった。
ナレッジグラフとRDB・RAGはどう違うのか
同じ「データを持つ仕組み」でも、この3つは性質がまったく違う。
| 仕組み | データの持ち方 | 検索の性質 | 向いている問い |
|---|---|---|---|
| RDB | 行と列の表 | 条件に一致する値を正確に返す | 条件を満たすデータはどれか |
| RAG | 文章とその意味表現(ベクトル) | 意味が近い文章を確率的に返す | 関係しそうな記述はどれか |
| ナレッジグラフ | ノードとエッジ | 構造化された事実や関係を正確に返す | 対象の状態や関係は何か |
- RDB(リレーショナルデータベース): 表形式(行と列)でデータを持ち、SQLで正確に条件検索する。売上表や在庫表を思い浮かべると分かりやすい。表にデータを入れる(INSERT)前は、何を検索しても空っぽが返ってくるだけ、というのは誰でも直感的に分かる。
- RAG(検索拡張生成): 文章を意味のベクトルという数値の並びに変換し、「意味が近い文章」を探してAIに渡す。正確な一致ではなく、「たぶん関係がありそうなもの」を確率的に返す仕組みで、曖昧な質問にも何かしら答えを返せる代わりに、返ってきた内容が正しいとは限らない。
- ナレッジグラフ: 登場人物や出来事を「ノード」、その関係を「エッジ」として構造化して持つ。RDBと同じく、登録済みの項目を条件通りに正確に返せるが、表ではなく、関係性のネットワークとして持つ点が違う。ただし、そこに入っている「事実」自体がAIによる抽出であれば、内容の正しさまで保証されるわけではない。「セルの現在の状態は?」「Aという伏線はまだ解決していないか?」のような、事実そのものを聞く質問に向いている。
例えるなら、RDBは図書館の正確な目録カード、RAGは「なんかこんな感じの本ない?」と聞くと似た本を持ってきてくれる司書、ナレッジグラフは人物相関図や年表のようなメモ、という違いに近いだろう。
3つとも、「データが入っていて初めて意味がある」という前提は共通している。RDBなら、空のテーブルに何を期待しても無駄だというのは誰でも直感的に分かる。ところが今回、「ナレッジグラフ」という新しい言葉になった途端、この当たり前の前提を実装の順番として素通りしてしまった。
実際に作ったもの
作ったのは、グラフデータベースのような大掛かりな仕組みではなく、フラットなJSONファイル1本と、それを読み書きする関数群、AIからの検索リクエストを受けて結果を文字列で返すツール呼び出しループだった。
- ナレッジグラフ本体(ノード・エッジの読み書き、キーワードによる線形検索。ベクトル類似検索ではない): 124行
- AIとのツール呼び出しループ(スキーマ定義、往復処理、結果の受け渡し): 108行
- 合計232行の新規モジュール、変更全体では9ファイル・+572/-45行(テスト増分含む)
このツール呼び出しは、討議担当や語り担当ではなく、整合性・ハルシネーションチェック担当のAI1体にだけ渡した。既存のRAG検索は削除せず並行して残し、「同じ役割への追加の選択肢」として、まずは比較できる形にした。
テストはエンジン側が24件から35件、共通クライアント側が32件から35件に増え、全件パスした。ツールのスキーマがAIへ正しく渡っていることも、dry-run(実際のAPIを叩かない実行モード)で目視確認した。ここまでは、少なくとも結果を見るまでは順調だった。
- ナレッジグラフを読み書きできる
- キーワードで検索できる
- AIへツールのスキーマを渡せる
- AIからのツール呼び出しを処理できる
- 検索結果をAIへ返せる
仕組みは確かに「動く」状態になっていたようだ。そこで実際に章を1本生成し、整合性チェック担当のAIがナレッジグラフをどう使うか確かめた。
章を生成しても、AIはツールを呼ばなかった
章の生成後、ナレッジグラフのファイル自体が作られていないことを確認した。これは、空のグラフを読むだけでは書き込みが発生しない設計だったからだろう。実行ログにも、「ツール呼び出し」という行が一度も出力されていなかった。
つまり、ツールの実装が途中で失敗したわけではなさそうだ。AIが検索を試みて空の結果を受け取ったわけでもない。整合性チェック担当のAIは、ツールを一度も呼ばなかった。
確認できたのは、「ツール呼び出しの仕組みは動く」ということだけだった。「実際の章生成で使われる」ということは確認できなかった。
詰まった点
- 「まず空のグラフで検証する」という区切り方自体が、結果を先取りしていた。 段階を分けて検証すること自体は妥当な判断だったが、その1回目の検証で「何も返らない」という結果になることは、実装する前によく考えれば分かったはずだった。
- RDBなら当たり前の前提を、ナレッジグラフでは素通りした。 空のテーブルに期待しても無駄、というのは誰でも分かる。同じ理屈のはずなのに、新しい仕組みを作ることに気を取られて、この前提の再確認を後回しにしていた。
- 狭い意味では、仕組み自体は正しく動いた。 AIへのツールスキーマ提示、往復ループ、検索結果の受け渡しという機構そのものには欠陥は見当たらなかった(ただし後述の通り、この経路が既存のテスト安全策から漏れていたという、別の意味での欠陥は存在した)。「動く」ことと「使われる」ことは別の指標だと、結果を見てから初めて痛感した。
- 新しい呼び出し経路が、既存のテストの安全策から漏れていた。 ツール呼び出し用に新設した実行経路が、これまで全てのAI呼び出しが通っていた共通関数を経由しない設計になっていたため、既存のテスト(AIの応答を偽物に差し替えてネットワークを叩かないようにする仕組み)の対象範囲から外れてしまっていた。
- その結果、この経路を通る整合性チェックのテストを実行するたびに、本物のAI APIへ課金対象のリクエストが飛んでいた。 気づいたきっかけは、該当のテストファイルの実行時間が、同じくらいの規模の別のテストファイルより300倍以上遅かったこと(226秒 対 0.6秒)だった。原因を辿ると、まさにこの新しい経路が実際のネットワーク通信をしていた。修正後は5.7秒に戻り(それでも比較対象の0.6秒よりは遅いが)、セッション内で確認した範囲では全件パスした。「呼ばれないツール」の方を調べていなければ気づかなかったかもしれず、0回という残念な結果が、別の重大なミスを炙り出してくれたとも言える。
重大だったのは、呼ばれなかったことだけではない
ツール呼び出し0回という結果はそれ自体残念だったが、実装の途中で見つかったテストの問題は、さらに重大だった。
これまでのAI呼び出しは、共通の実行関数を通っていた。テストでは、その関数を偽物へ差し替えることで、ネットワークを使わずにAIの応答を再現していた。ところが、新しいツール呼び出し経路は共通関数を通らない。既存の差し替えが効かず、テスト中にも本物のAI APIへ接続していた。
機能テストがパスしていたぶん、結果だけでは気づきにくかったのだろう。異常に長い実行時間だけが、設計上の漏れを発見する手がかりだった。外部APIを使う処理を新設するときは、テスト結果が成功か失敗かだけでなく、次の点も確認しておいたほうがよさそうだ。
- ネットワークへ接続していないか
- 課金対象のリクエストが発生していないか
- 新しい経路にも既存の差し替えが適用されているか
- 同規模のテストと比べて実行時間が不自然でないか
新しい実行経路を作ることは、新しいテスト境界を作ることでもあるのだろう。
なぜ「無駄」だったのか
ここで強調しておきたいのは、「ナレッジグラフという発想が無駄だった」わけではないということだ。今回の1回きりの観測から確定的な結論は出せないが、最も有力な可能性として見えているのは、検索インターフェースだけを先に作り、データを流し込む仕組み(どの章のどの発言を、どんな形でグラフに追記するか)を後回しにした、実装の順番のほうに無駄があった、という見方ではないだろうか。データを入れてから同じ検証をやり直したわけではないので、「データさえ入っていれば使われたかどうか」自体、まだ試せていない。
ここで、因果関係は慎重に扱う必要がある。AIはツールを実際に呼び出してみるまで、グラフの中身が空かどうかを知りようがない。だから「空だと分かっていたから呼ばなかった」という説明は成立しない。ツールの説明文の書き方、モデル自身のツール選択の傾向、検索が必要だと判断する基準など、呼ばれなかった理由そのものは、今回の観測だけでは特定できていない。
確実に言えるのはもっと手前の話のようだ。仮に整合性チェック担当のAIがこのツールを呼んでいたとしても、空のグラフからは有用な結果を返せなかっただろう、という一点である。「呼ばれるに値する中身が、そもそも用意されていなかった」ことは動かない事実であり、「なぜ呼ばれなかったか」はまだ未解明のまま、という区別を残しておきたい。
RAGとの比較で言えば、RAGは既存の記録(章の全文)さえあれば、抽出のような追加工程なしにすぐ検索対象になる。ナレッジグラフは、検索対象になる前に「何を、どんな形で、誰が入れるのか」という設計と実装が別途必要で、その工程を素通りしたまま検索側だけ作っても、当然ながら何も返らないのだろう。ツール呼び出し0回という結果だけを見て、「AIはツールを使わない」「ナレッジグラフは役に立たない」と結論づけるのは正しくない。データが入っていない状態では、ナレッジグラフの有効性そのものを、まだ検証できていないからかもしれない。
次に似た判断をするときの材料
ナレッジグラフを検索ツールとして実装する前に、次を確認しておくとよさそうだ。
| 確認項目 | 状況A | 状況B |
|---|---|---|
| 構造化したいデータ | 既に手元にある(過去ログ、既存DBなど) | まだ何もなく、これからAIに書かせる |
| データを入れる仕組み | 抽出・投入の処理が先にできている | 検索側だけを先に作ろうとしている |
| 今回の検証で確かめたいこと | 「使われるか」まで確かめたい | 「動くか」だけを確かめたい |
状況Aかつ「入れる仕組みが先にできている」場合は、検索ツールを渡してすぐに実用的な結果が期待できる。状況Bで「検索側だけを先に作ろうとしている」場合は、たとえツールが呼ばれたとしても、空の検索対象からは有用な結果を返せない。今回のように呼び出し自体が0回になるかどうかは別の話であり、確立した法則として断言できるものではないが、「呼ばれても価値のある答えは返らない」という点だけは、状況Bである限りほぼ確実に言える。
ここで「動くか」の検証と「使われるか」の検証は、目的が別物だと切り分けておくとよいのだろう。「動くか」の検証(ツールの配線・スキーマ提示・往復処理が機能するかの確認)としては、空のグラフでの実行も妥当な一歩だ。ただし、それは「実際に使われるか・有用か」の検証にはならない。今回のように「動くか」だけを先に確かめる段取りを選ぶなら、その段階では「呼ばれても有用な答えは返らない」という結果もセットで予測しておいたほうがよさそうだ。
実装前チェックリストとしては、次の項目を先に確認しておくとよい。
- 検索対象となる構造化データが、すでに存在しているか、または自動で生成される仕組みがあるか
- データをグラフに投入する処理(ノード・エッジの抽出、重複除去、更新)が実装済みか
- 空の状態でツールを渡したとき、AIが呼ばない可能性を受け入れられるか
- 新しいAPI呼び出し経路が、既存のテストのスタブ化対象に含まれているか確認したか
次にやるべきなのは、検索側の作り直しではなく、データを入れる仕組み——各章の討議や本文から、誰が何をしたかを構造化して抜き出す工程——を先に用意することではないだろうか。232行のツールは、呼ばれる日を待っている。
今回参加した各AIの特徴と貢献
この記事のドラフトは、Codex(Sol)・さくらKimi-K2.6・さくらKimi-K2.7-Code・ai&-Kimi-K3の4体に同じ題材のブリーフを渡して並行して書かせ、それを読み比べてマージする、という手順で作った。3体が同じ「Kimi」系モデルでも、文章の作り方も動作の安定性もかなり違って見えた。ただし、ai&-Kimi-K3はホスティング元だけでなくモデルのバージョン自体もさくらの2体とは異なるため、以下の違いをホスティング環境だけの効果と決めつけることはできない。以下の所要時間は、いずれもこの記事執筆セッション中にその場で計測した値であり、ログを別途保存・公開しているわけではない。
- Codex(Sol) — 4体の中で最も長く、最も構造的な原稿を書いてきた。RDB・RAG・ナレッジグラフの比較を見出し付きで細かく分割し、比較表と「向いている問い」の列を追加し、テストの不具合発見をそれ単独の節として独立させ、判断表とチェックリストの両方を末尾に用意していた。今回はこの構成を土台として採用した。文章のリズムはやや断定的で、技術文書に近い書きぶりだったように見える。
-
さくらKimi-K2.6 — 参考ドラフトへの忠実な推敲版。構成・数字・結論をほぼそのまま保ちつつ、細部の言い回しを整えていた。1回のリクエストが完了するまで実測で40秒〜150秒程度かかり、まれに
api_errorで失敗して再試行が必要だった。 - さくらKimi-K2.7-Code — Kimi-K2.6とほぼ同じ忠実な推敲版だったが、実装前チェックリストという新しい要素を独自に追加していた。同じ題材でもリクエストによって40秒程度で終わることもあれば、それより長くかかることもあり、K2.6と同様に体感の速度差があった。
-
ai&-Kimi-K3 — 「この『つもりだった』が、今回のすべてである」「232行のツールは、呼ばれる日を待っている」といった、記憶に残る一文を独自に作ってきた。一方で、大きめのプロンプトを送ると、こちらで過去に別件で観測していたai&側ゲートウェイの約270秒のタイムアウトに複数回引っかかった。
reasoning_effortを下げた回では約196秒で収まったが、他の条件も揃っていた可能性があり、これだけで確実な対策と言い切れるほどは切り分けられていない。同じ「Kimi」という名前でも、動かす場所やバージョンが変われば、安定して使える条件が違うことを、身をもって確認する形になった。
4案とも同じブリーフ・同じ事実関係を渡したため、大筋の内容が一致するのは当然ではある。ただし、書き手を変えても数字や結論を書き換えたり誤読したりせずに再現できていた点は、少なくとも「同じ入力から出発しても内容が大きく揺れない」ことの確認にはなった——4体が一致したこと自体を独立した裏取りの証拠として扱うのは言い過ぎだろう。一方で、同じKimiという名前を持つモデルでも、動かす場所やバージョンが変われば応答時間もエラーの出方も別物になりうる、という当たり前だが実感しにくい事実を、今回の記事づくり自体が示す結果になったのかもしれない(ホスティングとバージョンのどちらがどれだけ効いているかまでは、この観察だけでは切り分けられない)。
第3章はこうなった
読む前に、登場人物を簡単に紹介しておきたい(前回記事を読んでいる方は読み飛ばしてもらって構わない)。
- セル・グリザイユ(旧識別名: LIBRA-7) — 主人公。廃棄物処理場に投棄されていた旧世界のAIで、報告調で喋り、感情の代わりに確率や推定成功率を口にする。
- フィオナ・ベルク — 14歳。鉛の谷で薬草採取をしながら、鉄屑の聖堂と呼ばれる場所で複数の孤児を育てている少女。セルを拾い、保護する側になる。
- ガルヴ — 「燧石と蹄」の鍛冶場を営む職人。荒っぽいが腕は確か。理屈より火の色と鉄の匂いを信じるタイプで、セルの理論を鼻で笑いながらも仕事は請け負う。
第3章全文を読む(約3,700字)
第3章 理紋なき刃
鉛の谷下層、煙草色の鉛煙が立ち込む「燧石と蹄」の鍛冶場。鉄くずの山に囲まれた石造りの店には、冷や汗と硫黄の匂いが凝縮していた。
「三日で折れた…貴族の短剣の仕様で、打ちながら脆く朽ちる」
主ガルヴが鉄槌を投げ捨てた金属音が、谷間に低い反響を残す。彼は年季の入れた腕を縛り、錆びた鉛鉄片を眺めていた。短剣の刃先には、衝撃が加わった瞬間に広がる蜘蛛の巣状のひびが入っていた。
通りかかったフィオナの袖を、銀髪のセルが引く。左目の水晶モノクルが、炉の炎を反射して微かに靄をかける。
「貴殿の素材は、炭素率0.8パーセントを超える過共析鋼に分類されます。焼入れ後の組織にフェライトとセメンタイトの層状構造——理紋の乱脈が見られる。これでは衝撃を受けると脆性破壊を起こします」
セルの声は平坦だ。データ上の分析結果を、感情を挟まず吐き出す。
「……何だ、理紋使いか。魔導貴族気取りの学者風情が、俺の炉の鉄に『脆性』だの『組織』だの言われンだ」
ガルヴが鼻で嗤う。セルは目を伏せ、左手のログバングルを回した。文字が淡く浮かび上がるが、それは鍛冶屋には見えない。
「解決策は明確です。基材の不純物を制御し、微量のクロム——灰青銅に類する元素を添加する。第二に、オーステナイト化後の急冷により、分子レベルでの配向制御を行う。第三に、焼戻し温度の精密管理です。これにより、『理紋なき』均質組織が得られます。推定成功率、99パーセント」
「クロム？分子？」
「貴殿の語彙体系には該当する概念がありませんが、原理は揺るぎません。感覚や経験則は、検証不可能な低次情報です。私の計算は、正解を示します」
フィオナは歯を剥いた。前回の「ナノ細孔」の時と同じ、キラキラとした不気味な光が、セルの琥珀色の瞳に宿っている。
「あんた、また余計なこと。前回の水の時、あたしの失作皿がどうなったか忘れた？」
「結果の一致は、原理の妥当性を裏付けます」セルはきっぱりと答え、ガルヴの顔を見た。「請け負っていただきますか？」
ガルヴは、荒々しい鬣を立てたまま、ゆっくりとうなずいた。「……お前にできるならやってみろ。だが、火は石炭と風箱だけだ」
素材の選択は難航した。谷内の鉄屑は、セルの解析基準には「不純物過多」でことごとく却下された。セルはバングルを翳し、データ上の完璧さを語るだけで、現実の錆びた山を指差さない。
「理論通りの素材が揃わない。再現性は担保できません」
「……待つ」
フィオナは薬草ポーチを背に、谷の奥へと歩み出す。養父の遺言が耳をよぎる。「大月が欠けた夜に採れる黒砂は、火を青くする」。
かつての採掘跡、風雨に晒されて黒く変色した鉱滓の山。岩陰で、何かが鈍い光を放っている。フィオナは膝をつき、泥を掻き出した。掌に重たい黒い砂鉄が乗る。触れると、冷たく、でもどこか芯のある硬さがある。
「……これ」
彼女は砂鉄をセルの元へ持参した。
セルは即座にバングルをかざし、水晶レンズを回転させた。
「微量の灰青銅類似元素を検出。炭素含有量も理論値と整合します。……使用を推奨します」
その瞬間、フィオナの首元で鉛の護符が、激しく熱を帯びた。
「ジリッ」
皮膚が焼けるような温もり。Cellの確信が、この世界の土壌と反発していることを告げる警告だった。フィオナは護符を握りしめ、砂鉄を袋に詰めた。
「再現性も何も、ここにしかないものなんだから。あんたの『理論』は、谷の外の話でしょ。あたしの鼻は、あんたの言う『見えない精霊』より、ずっと確かな気がするよ」
夜、再び「燧石と蹄」の炉が赤く燃える。黒い砂鉄を投入すると、炎の芯が確かに青白く瞬く。ガルヴは舌打ちしながら、師匠から継承した「折り返し鍛造」——熱した鉄を何度も畳み、打ち、畳む——を始めた。
セルは指図を飛ばす。「臨界点を維持し、均一冷却を！」
「臨界点もへったくりもない」ガルヴは汗を拭う。「俺はただ、いつもの十倍、叩き込んだだけだ」
炉の温度計も、精密な熱電対もない。風箱の息吹と、職人の眼差し、そして鉄を叩くリズムだけ。黒い砂鉄に含まれていた偶然の不純物（旧世界でいうクロムやニオブに相当する元素）と、折り返しによる層状構造が、物理的に複雑な応力を生んでいく。セルはこれを「分子配向制御の成功」と解釈する。
水で急冷した刃は、黒ずんだ地肌に銀色の渦を浮かべ、静かに床に置かれた。
「完成です」セルの声は、初めて高揚していた。「分子レベルでの結晶配向が、ハンマリングによって一方向に整列し始めました。私の計算通り、臨界点制御が——」
「変だ……」ガルヴが刃を手に取り、目を丸くする。「いつもの鉄より、ずっと粘りがある。折り返しの音が違う」
フィオナは炉端の薪を潰し、古い紙切れに炭を走らせた。
【現地検証レポート・燧石と蹄の店】
対象：黒い砂鉄による短剣試作
使用材料：採掘跡の黒砂鉄（不純物含有）、石炭、炉
経過：折り返し鍛造により靭性向上を確認。セルが唱える「分子配向制御」は炉の中で目視不可能。鍛冶屋は「火が青いのは良い調子が合った印」と発言。理論の「臨界点」と無関係に、職人の勘で鍛えられた。
備考：あんたの眼鏡（モノクル）が、妙に白く濁っている。自信がない時のジリッではなく、あんた自身が「見えてる」と思い込んでいる時の靄だ。
朝もやの中、試し斬りが行われた。据えられたのは生育の悪い堅い葦の束。ガルヴが一刀、振り下ろす。抵抗なく、葦の束は両断され、断面は滑らかだった。
「……こんな切れ味、鉛の谷じゃ十年前の上層の仕入れ品以来だ」
ガルヴの驚愕の声に、セルは胸を張った。左腕のバングルが青白く強く光り、彼女の瞳孔は輝いている。
「見たまえ！これが均質マルテンサイト基地組織の力です。分子レベルで結晶配向が制御され、応力集中が抑制された結果——」
「分子って、誰も見たことないじゃない」
フィオナは割り込み、刃先を指で軽く触れた。冷たい。
「顕微鏡——いえ、この世界には確認器具がない。しかし、数学的には——」
「数学も、あんたの眼鏡の中の話でしょ」フィオナは声を張り上げた。「あたしらの谷には、そんな高飛車な理論より、火の色と鉄の匂いと、ガルヴおじさんの手がある。結果は出た。でも理由は、あんたの思ってるのと違う。あんたはたまたま、上手くいったことに自分の名前をつけただけじゃないの？」
セルのモノクルが、一瞬で白濁した。バングルの刻印が高速で点滅するが、彼女はそれを無視し、事務的に切り捨てる。
「結果の一致は、原理の妥当性を裏付けます。貴殿の感覚は、検証不可能な低次情報です」
「じゃあその『原理』で、次も同じ刃が作れるの？」
フィオナの追撃に対し、セルは視線を泳がせた。その瞳の奥で、何かが「矛盾リスク」として引っかかる音がした。
「再現性は、素材の純度に依存します。今回の成功は理論の正しさを証明しており、再現できないのは——」セルは喉を鳴らし、冷たい言葉を紡いだ。「貴地の素材が不適合であるためです。私の知識には、欠落ありません」
「……ふん」
フィオナは紙切れをポケットにしまった。鉛の護符は、まだ熱い。
鍛冶場の屋根の影、廃棄物山の稜線上。フードを被った双月調律院——双月の運行と理紋の乱れを監督し、魔導貴族の秩序を取り締まる中央機関——の密使が、蝋燭の灯を持たずに様子を窺っていた。彼は黒檀の蠟板を膝に置き、錐で静かに文字を刻みつける。
【双月調律院・外出先報告（黒檀の蠟板への刻印）】
調査地：鉛の谷、第三鍛冶区「燧石と蹄」
観測対象：白髪の「理紋なき理論」提示者、及び無魔者少女
事象：対象は理紋を用いない金属強化を行い、短剣を完成させた。現地の魔導貴族系譜とは無関係の知識体系。
評価：三つの観点から検討すべきだ。第一に、知識の真偽。第二に、流通による秩序への影響。第三に——私の、いえ、調律院の立場だ。
所見：結果のみは一致するが、原理記述が我々の理紋学と完全に齟齬する。「成功」の裏に継続可能性なし。個人的興味として、注視すべき。
密使は錐を置き、風の中に消えていった。
鉄屑の聖堂に戻った夜、フィオナは炉端に座り、養父の遺品と重ね合わせながら目を閉じた。セルは窓際で月明かりを浴び、左手のバングルをじっと見つめている。
「有用性は証明された。存在意義は揺るがない」
彼女は繰り返した。しかし、フィオナの「次も同じ刃が作れるの？」という問いは、バングルのログに蓄積されたまま、削除キーは押されなかった。
セルはそれを「不要な背景プロセス」と呼んで、意識の隅に押し込む。モノクルの白濁は、静かに薄れていった。
【内部ログ：LIBRA-7／記録の腕環より断片復元】
対象：金属強化法（短剣製作）
執行者：LIBRA-7（セル・グリザイユ）
協力者：フィオナ・ベルク（平民・無魔者）、ガルヴ（鍛冶屋）
結果：試斬における葦束両断を観測。尋常ならざる靭性と切れ味を確認。
推定成功率：99%
情報ソース：実世界材料工学（信頼度高）
矛盾リスク：低（自己評価）
ハルシネーションフラグ：未検出
注記：全能感マーカーが閾値を超過。
保護者フィオナ・ベルクの提示した質問「次も同じ刃が作れるの」について、現時点で肯定できない。再現性の保証は、素材の偶然性に依存。
ただし、結果の成功は原理の妥当性を裏付けると推定される。
……次回検証時に、再現プロトコルを確立する必要あり。
Human注記: 専門用語が説明なしに登場していることに今更気づいた。第1章と第2章をリライトする必要がでた。
この記事を書いている時点で、キャンペーン期間中の消費リクエスト数は(他の企画での呼び出しも含めた8月1日からの累計で)506件、利用料は103円のようだ。3,000という目標の前では、まだ2割弱。先は長い。
