JSONとTOON

JSONからの続き

JSON（JavaScript Object Notation）はjavaScriptの表記法に由来するデータ交換

用テキストフォーマットの一つで様々な言語で共通に利用できる。データ型は

""で囲まれた文字列に限られ，:を含んで{}[]と多重に囲まれている。これをLLMで

受け渡すと，無駄に課金トークンが消費される場合もある。

最近，TOON（Token-Oriented Object Notation）という，LLM専用に最適化された

新しいデータフォーマットが提案されているらしい。40-60%も効率化されるとか。

うまい話に飛びついてはいけない。さっそく各生成AIに尋ねてみたところ・・・

(1) ChatGPT：（だめだこりゃ）

「JSON と TOON を比較してください」というご質問ですが、TOON という名称の仕様・フォーマットは複数存在しており、文脈によってまったく別物を指します。

(2) Gemini：（ほぼ正しそうだ）

JSONとTOONの主な違いは、その設計思想と用途にあります。簡単に言えば、JSONは汎用性と人間/機械の可読性を重視したデータ形式であり、TOONは大規模言語モデル（LLM）との通信におけるトークン効率を極限まで高めることに特化した新しいデータ形式です。

(3) Claude：（それっぽいがフェイク）

JSONとTOMLを比較します。

基本的な特徴

JSON (JavaScript Object Notation)

TOML (Tom's Obvious, Minimal Language)

(4) Kimi：（これもほぼ正しそうだ）

JSON と TOON は、どちらも構造化データを扱うためのフォーマットですが、設計思想と得意な場面が異なります。以下に特徴と使い分けをまとめました。

JSON（JavaScript Object Notation）とは？

TOON（Token-Oriented Object Notation）とは？

(5) DeepSeek：（一見それらしいフェイク）

JSON（JavaScript Object Notation）とTOON（Telegraphic Object Notation）はどちらもデータ交換フォーマットですが、設計思想や用途に違いがあります。以下で詳細に比較します。

(6) Perplexity：（弱々しくて(2)(4)に劣る）

JSONとTOONはどちらもデータ記述フォーマットですが、設計思想や用途に大きな違いがあります。TOONは、特にAIやLLM（大規模言語モデル）処理向けに新たに設計されたもので、JSONと比較して効率性・柔軟性・表現力に強みがあります。​

(7) ChatGPT Thinking：（更問いしてみた・・・微妙に自信なさげ）

ここでいう TOON は、最近公開された Token-Oriented Object Notation（LLM向けのデータフォーマット）だと仮定して比較します。もし別の TOON を指していたら教えてください。

日によって調子の波のアップダウンが激しい生成AI（LLM）チャットボットさん達。

［１］JSONを超える？新データ形式「TOON」とは｜仕組みと使いどころ（SEへの道）

［２］みたことないファイルフォーマットTOONとやらを試してみる（Akasan）

［３］AI時代のデータ形式 JSONからTOONへ（The Prince Academy）

四項間漸化式（２）

三項間漸化式（２）・四項間漸化式（１）からの続き

四項間漸化式の場合も同様に考えて，三項間漸化式に帰着させればよいわけだ。最初間違った方針でトライして，Mathematicaに無理矢理答えを出させたら美しくなかったのだけれど，昼寝の前に思いついたらなんということはなかった。たぶん。

① $a_n=p a_{n-1} -q a_{n-2} +r a_{n-3} \quad (n \ge 3)$を考える。ここで。$p,\ q,\ r, \quad a_0, a_1, a_2$は与えられているものとする。

② 次の変形をちょっと工夫する。$a_n-\alpha a_{n-1}= (\beta + \gamma) ( a_{n-1} - alpha a_{n-2} ) - \beta \gamma (a_{n-2} - \alpha a_{n-3)} $ とすれば，①と比べて，$p= \alpha + \beta + \gamma $，$q = \alpha \beta + \alpha \gamma + \beta \gamma$，$r = \alpha \beta \gamma$となる。

③つまり，$\alpha, \ \beta, \ \gamma$は，３次方程式 $ t^3-p t^2 + q t - r = 0$の3つの解とすればよいわけだ。

④このとき，$b_n \equiv a_n -\alpha a_{n-1}$と定義すれば，①すなわち②は，$b_n = (\beta + \gamma) b_{n-1} -\beta \gamma b_{n-2}　\quad ( n \ge 3)$　という三項間漸化式に帰着する。

ただし，$b_1= a_1 - \alpha a_0$，$b_2 = a_2 - \alpha a_1$ は$\alpha$が定まれば，それに応じて与えられる。

⑤ この三項間漸化式はさらに，$b_n - \beta b_{n-1} = \gamma (b_{n-1}- \beta b_{n-2})$ とできるため，$c_n \equiv b_n - \beta b_{n-1}$と定義すれば，$c_n = \gamma c_{n-1} \quad (n \ge 3)$

となる。ここで $c_2 = b_2 - \beta b_1$は，$\alpha, \ \beta$ の値に応じて与えられるため，一般項は，$c_n = \gamma^{n-2} c_2 \quad (n \ge 3)$ と求まることになる。

⑥あとはこれを逆にたどれば最終的な$a_n$にたどり着くけれど，$\alpha, \beta, \gamma$としてどの値をとるかの場合分けが少なくとも6通りあるし，重解の場合の処理とか実際にはいろいろと面倒な気がする。最終的には $a_n = k_1 \alpha^n + k_2 \beta^n + k_3 \gamma^n$的なところに落ち着くはずだと思われる。

P. S.  $a_n=t^n$ と仮定すると，$a_n=p a_{n-1} -q a_{n-2} +r a_{n-3}$ に代入して，$t^n =p t^{n-1} -q t^{n-2} + r t^{n-3} $ が成り立つ。$\therefore t^3-p t^2 + q t -r = 0$となるので，この三次方程式の解を $\alpha, \beta, \gamma$ として，$\alpha^n, \beta^n, \gamma^n$ はもとの漸化式を満たす。漸化式の線形性からそれらの線形結合も漸化式を満たす。つまり $a_n = k_1 \alpha^n + k_2  \beta^n + k_3  \gamma^n $となる。$a_0, a_1, a_2$の初期値を与えれば，三元連立方程式を解いて，$k_1, k_2, k_3$が求まる。

三項間漸化式（２）

三項間漸化式（１）・リュカ数列からの続き

金沢泉丘高校では数学の授業が数甲と数乙に分かれていて，それぞれ別の先生が担当されていた。結局，松川先生（マッチのお父さん）と楠先生（あだ名はパチ）と西野先生（近所にお住まい）の組み合わせだった。楠先生も西野先生もなんだか女子生徒に人気があった。

ちょっとこわもて風の西野先生は，教科書を使わずに独自の解法をたんたんと説明していくのだった。そのなかに数列の漸化式の話があったはずだけれど，漸化式をずらっと並べて総和をとる方法だけ何となく印象に残っていた。今回，一般式をあれこれいじっているとその修正版が登場した。もしかしたら習っていたかも知れないけれど，そこはちょっと記憶になかった。

①漸化式は次のとおりである。$a_n= p a_{n-1} - q a_{n-2}\quad (n \ge 2)$ ここで，$p,\ q$ および$a_0$と$a_1$は与えられている。これから一般項$a_n$を求めたい。

②①の漸化式を次のように変形する。$a_n - \alpha a_{n-1} = \beta (a_{n-1} - \alpha a_{n-2}) \quad ( n \ge 2)$ ただし，$\alpha + \beta = p \quad \alpha \beta = q $から $t^2 - p t + q = 0 $という$t$の二次方程式の解が，$\alpha と \beta$ であり，重解の場合と2通りの別解の場合の可能性がある。

③$b_n \equiv a_n - \alpha a_{n-1}$と定義すると，②の式は $b_n = \beta b_{n-1}\quad (n \ge 2)$となる。$b_1=a_1 - \alpha a_0$ も与えられるので，$b_n = \beta^{n-1} b_1 \quad (n \ge 2)$と解ける。

④これから次の一連の式が出てくることになる。

$ \quad \ \ a_n \ \ - \alpha a_{n-1} \  \ = \quad \ \beta^{n-1} \ b_1 \quad (n \ge 1)$

$ \ \alpha \ ( a_{n-1} - \alpha a_{n-2}  )= \ \alpha \beta^{n-2} \ b_1 \quad (n \ge 2)$

$ \alpha^2 ( a_{n-2} - \alpha a_{n-3}  )= \alpha^2 \beta^{n-3} \ b_1 \quad (n \ge 3)$

$\quad \quad \cdots$

$ \alpha^{n-1} ( a_1 \ - \ \alpha a_0  )\ =\  \alpha^{n-1} \beta^0 \ b_1 $

これを辺々すべてたしあわせると，

$\displaystyle a_n - \alpha^n a_0 = \sum_{k=1}^n \alpha^{k-1} \beta^{n-k}\ b_1 = \beta^{n-1}\ b_1 \sum_{k=1}^n \Bigl( \dfrac{\alpha}{\beta} \Bigr)^{k-1} = \beta^{n-1}\ b_1 S_n$

⑤したがって，$a_n = a_0 \alpha^n + b_1 \beta^{n-1} S_n = a_0 \alpha^n + (a_1 - \alpha a_0) \beta^{n-1} S_n$

⑥ (1) $\alpha= \beta$の場合： $S_n=n$　$\therefore a_n = a_0 \alpha^n (1-n) + a_1 \alpha^{n-1} n$

　 (2) $\alpha \neq \beta$の場合： $\displaystyle S_n = \dfrac{\beta^n-\alpha^n}{\beta - \alpha}$　$\displaystyle \therefore a_n = \dfrac{\alpha \beta (\alpha^{n-1} - \beta^{n-1})}{\beta - \alpha} a_0 + \dfrac{\beta^n - \alpha^n}{\beta - \alpha} a_1$

（例）フィボナッチ数の場合（$a_0=1,\ a_1=1 \quad \beta = \frac{1+\sqrt{5}}{2}, \ \alpha = \frac{1-\sqrt{5}}{2}$）

$\displaystyle  a_n=\dfrac{\beta \alpha^n - \alpha \beta^n}{\beta - \alpha} \cdot 1 + \dfrac{\beta^n - \alpha^n}{\beta - \alpha} \cdot 1 = \alpha^n \dfrac{\beta -1}{\beta - \alpha} + \beta^n \dfrac{1-\alpha}{\beta - \alpha}$

　$= \frac{1}{\sqrt{5}}\Bigl\{ \alpha^n \dfrac{\sqrt{5}-1}{2} + \beta^n \dfrac{1+\sqrt{5}}{2}\Bigr\} = \frac{1}{\sqrt{5}}\Bigl\{ \bigl( \dfrac{1+\sqrt{5}}{2}\bigr) ^{n+1} - \bigl( \dfrac{1-\sqrt{5}}{2}\bigr)^{n + 1} \Bigr\} $

AI対話計数ツール

対話の時代・ブログ保存ツールからの続き

2022年11月30日にChatGPTが公開されてから，そろそろ3年目を迎える。おかげさまで，このブログがAIとの対話によって侵食されてきた。それを定量的に分析するために，前回ブログ保存ツールで保存したpdfファイルの分析とカウントをするプログラムを作ろう（作らせよう）と考えた。実際の分析は11月の末日を待ってからになる予定。

2日かけて，3回目のリセットでようやく目的のものにたどり着いた。修正を繰り返すとどんどんドツボにハマっていくので，今のレベルでは仕様を再確認してリセット（最初からやり直し）がよい。なお，これは自分専用だ。なぜならば，Ｑ（koshix）：，Ａ（ChatGPT）：のような構造に準じたものだけをカウントするように設計したためだ。

最初の頃はでき上がったpythonコード（160行ほど）を自分で実行してチェックしていたが，そのうち，あらかじめ正解データを入れて，ChatGPT側でチェックするようにした。途中でOCR機能が必要だとかいいだして実行時間が2桁大きくなってしまったので，それはやめてもらった。ほとんど通常のデバッグ作業のように対話が進んでいく。

Ｑ（koshix）：

自分のブログの一月分のデータ（pdfファイル）のテキストを分析したいと思います。

(1) 毎日のブログで，生成AIとの対話を使っているかどうかを調べます。

(2) 当月の1-31日(月末)の各日について，使っていれば○，そうでなければ△のリストを出します。 例えば，以下のような形式のリストのcsvファイルになります。 2023-12 1,○ 2,△ ・・・

(3) 日付の区切りは例えば，2 0 2 2 年 1 2 ⽉ 2 ⽇ ⾦ 曜 ⽇，のようなものになります。 ・pdfファイルは当月の末日から初日に向かって並んでいます。 ・pdfファイルの初日以降に前月分のブログがある場合がありますが無視してください。

(4) 判定条件は以下のとおりです。

・生成AI発言を使っている場合は，Q: A: の構造が段下げの状態で含まれている。 大文字小文字は区別せずに，{Ｑ，Ｑ Users，Users，Ｑ（koshix）： }などと対応する{Ａ，Ａ ChatGPT，ChatGPT，Ａ（ChatGPT-5）：} など につづくテキストのブロックがある。 ・ChatGPT-5 のところには，ChatGPT，Gemini，Claude，Perplexity，Grok，DeepSeek，Qwenなどの文字列を含んだ各バージョンの名称が入ることがある。 ・それ以外の要素は加味しなくても良い。

(5) これを実行するpythonスクリプト名を ai.py とすれば，コマンドラインで ai.py 2025-10.pdf とかai.py 2024-*.pdf などとすれば，2025年10月分のファイルの分析や，2024年の1月から12月のファイルの分析がワイルドカードでできるようにします。

(6) 上記の例で結果出力は，2025-10.csv，2024-01.csv 〜2024-12.csv （12ファイル） が得られます。複数月を指定した場合は，それぞれの月の○の数を集計したものの 月別リストを summary-2024.txt などとしてまとめ出力してください。

(7) 見本ファイル（2023-05.pdf）とコメント付きの正解のcsvテキストを添付（省略）します。

質問があれば教えてください。

Ａ（ChatGPT-5 Thinking，24秒）：

意図：（回答略）

できること：（回答略）

スクリプトと実行例：（回答略）

使い方：（回答略）

実装の要点（抜粋）：（回答略）

既知の限界と調整ポイント：（回答略）

追加の検証や、「この月のこの日が××のはず」などの正解表に合わせた誤判定修正（パターン拡張や閾値変更）もすぐ対応します。まずは上記 ai.py と 2023-05 の結果をご確認ください。

Ｑ（koshix）：

(1) 28,○ と 30,○ が再現できていません。その理由を教えてください。

(2) csvファイルの末尾に○の数の集計値を与えてください。

(3) 有る年度の複数のpdfファイルを対象にした場合，summary-2023.txtのようなまとめファイルをください。それは，各月名と○の数がならんだcsvファイルです。 2023-01, 5 2023-02, 9 ・・・ 2023-12, 10 などのようなものです。

Ａ（ChatGPT-5 Thinking，17秒）：

ありがとうございます。ご指摘の3点、以下の通り対応しました。

(1) 28,○ と 30,○ が再現できていなかった理由（回答略）

(2) CSV の末尾に ○ の集計値を追加（回答略）

(3) 年度まとめファイル summary-YYYY.txt（回答略）

更新済みスクリプト（rev2）：

ai.py を差し替え済みです。ダウンロードしてそのままお使いください。

スクリプト：Download ai.py

サンプル出力（今回のPDFに対する再解析結果）

2023-05.csv（末尾に 合計○ を追加済み）

summary-2023.txt（CSVスタイル）

必要なら、Q/Aラベルの追加（例：質問/回答、ユーザ の表記揺れ、モデル名の拡張など）や、「Q→Aの順序」判定の厳格化/緩和（例えば同一行Q/Aを○とみなす等）も即調整します。

Ｑ（koshix）：

ほとんどよくなりましたが，どうして6が○になりますか。△のはずですが。

Ａ（ChatGPT-5 Thinking）：

ご指摘ありがとうございます。原因の分析と修正を反映しました。

なぜ「6」が誤って○になったのか

誤判定の典型パターンが当たっていました：

「Q&A（イベント案内・章タイトル）」型：本文中に “Q&A” や “Q & A” の語があり、同じ日の本文内に “ChatGPT” 等のモデル名が登場するだけで、「Q→A の対話」と誤認。

ラベルなしの一般語：User（ユーザー）や ChatGPT が見出しや説明文中に現れるだけでも、（緩め過ぎた rev2 の）正規表現が「Q/Aラベル」とみなしてしまう。

つまり 「Q（やUser）+ … + ChatGPT」 の単なる共起を、「行頭の話者ラベルによる Q→A 対話」と誤解するケースがあり、6日が○に転んでいました。

対策（rev3）（回答略）

ダウンロード（回答略）

仕様の最終確認（回答略）

もし「この日も○/△が違う」といった箇所があれば、その日の**短い抜粋（スクショでも可）**をお知らせください。検出器をピンポイントで微調整します。

Ｑ（koshix）：

30が○から△に変わりました。これはなぜですか。テキストを添付します（略）。

Ａ（ChatGPT-5 Thinking，9秒）：

原因はシンプルです。rev3 で検出条件を“行頭ラベル＋コロン必須”に厳格化したため、30日の本文にある

User（単独行、コロンなし）

ChatGPT（単独行、コロンなし）

という**「見出し型の話者ラベル（コロンなし）」**が Q/A ラベルとして認識されなくなったからです。

添付テキストはまさにこの形式で、各ラベルの次の行から本文が始まっています。そのため rev2 では○、rev3 では条件を満たせず△になりました。

どう直せば 30 日が○に戻るか（最小変更）（回答略）

必要であれば、この修正を組み込んだ ai.py (rev4) をすぐにお渡しします。

Ｑ（koshix）：

ai.py（rev4）をください。

Ａ（ChatGPT-5 Thinking）：

お待たせしました。rev4 を作成して動作確認済みです（5月の○の合計は10に変化：6日＝△のまま、30日＝○に復帰）。スクリプト本体，検証出力，年次まとめ，rev4の要点など（回答略）

これでほぼできあがり，第３回の所要時間は30-60分ほどだろうか。

図：AIとの対話（Imagenが私の正面写真から生成した横顔）

［１］pdf2aiのソースコード（2025.10.21）

ブログ保存ツール

しばらく前に一度やりはじめて挫折した件。再度，要求仕様を良く考えてChatGPT-5 Thinking に依頼してみた顛末が以下のとおり。かなり苦労したが目的は一応たっせられた。このブログ記事を月単位でpdfにアーカイブするというものだ。

その過程でわかったことがある。ChatGPT-5の能力を持ってしても，単純な構文エラー（［］の数がつり合わない）を生ずることがある。一方で原因不明のトラブルが発生した。これは未解決のままだ。2020年6月分のアーカイブの際に，wkhtmltopdfがうまく機能しないというもの。いちおうの回避プログラムも提案してもらったので，なんとかはなっている。

pythonを使う際には仮想環境にしないといけないのがちょっと面倒だ。

% brew install wkhtmltopdf

% python3 -m venv path/to/venv

% source path/to/venv/bin/activate

(venv) % python3 -m pip install --upgrade pip

(venv) % python3 -m pip install pymupdf requests beautifulsoup4 numpy playwright

(venv) % ./blgpdf 202510 202510

などなど。

Q（koshix）:

私は，https://koshix.blogspot.com に2018年12月から毎日ブログを掲載しています。

このデータを月単位でpdfファイルとしてダウンロードしたいと考えています。

例えば https://koshix.blogspot.com/2025/09/ とすれば，2025年9月分のデータにアクセスすることができます。ところで，この場合9月21日までが1ページにまとまって出力されますが，それを越える部分（9月20日以前）は，ページ末の「前の投稿」からたどる必要があります。

これによって，次の1ページで9月1日までのデータにアクセスすることができます。ブログの分量によっては，1月分が1ページで収まる場合もありますが，今のようにそうでない場合もあります。おおむね2ページで収まると考えています。

さて，このような状況で月単位のpdfファイルを取得するのですが，実際に試してみると1ページのpdfの後半には連続したブランクページがたくさん含まれているようです。できればこの空白を取り除いた上で，1ページ目ともしあれば2ページ目（これも空白を取り除く）をつなげた１本のpdfファイルにまとめてほしいのです。ファイル名は例えば，2025-09.pdf などとなります。

このような仕事をコマンドラインから実行するプログラムを作ってください。そのプログラム名を blgpdf とすれば，blgpdf 202506 202509のようにすれば，2025年6月から2025年9月までの4つのファイル（6月,7月,8月,9月）が得られるようにしたいのです。

ここまでで何か質問はありませんか。なければあらためて依頼のゴーサインを出します。

Ａ（ChatGPT-5 Thinking，35秒）：

ありがとうございます。要件は把握しました。実装前に最小限だけ確認させてください（全部 “はい/いいえ/短文” で返せます）：

１．依存ツール：wkhtmltopdf（HTML→PDF化）＋ Python パッケージ PyMuPDF（空白ページ検出と削除）を使ってよいですか？

・macOS（Homebrew）で brew install wkhtmltopdf、pip install pymupdf を想定しています。

２．空白ページの扱い：文中に紛れ込んだ“実質的に真っ白なページ”も削除対象にしてよいですか？（末尾に連なる白紙だけでなく、途中にあっても除去）

３．出力場所：デフォルトは「カレントディレクトリ」に YYYY-MM.pdf を保存でよいですか？（例：./2025-09.pdf）

・もし希望があれば --outdir オプションを付けます。

４．レンダリング待ち：Blogger の遅延読み込み対策として、wkhtmltopdf --javascript-delay 2000（2秒待ち）を入れます。既定で問題なければこの設定で進めます。（必要なら秒数を指示ください）

５．2ページ目URLの検出：月ページ下部の “前の投稿 / Older posts” リンク（search?updated-max= を含む）を自動検出して拾う方式で問題ないですか？（テーマ依存のラベル文言差は無視し、URLパターンで判定します）

OK でしたら、すぐに blgpdf（単一ファイルのPythonスクリプト、CLI）をお渡しします。

例：blgpdf 202506 202509 → 6〜9月を順に取得・白紙除去・結合・保存。

Ｑ（koshix）：

1 yes 2 no 3 yes 4 yes 5 yes 　これですすめてください。どうぞよろしくおねがいします。

Ａ（ChatGPT-5 Thinking，20秒）：

了解です。ご指定どおり進めます。（以下略）

Ｑ（koshix）：

空白ページの除去が全くできていないので，2000ページものpdfが出力されていました。 なんとかなりませんか。

Ａ（ChatGPT-5 Thinking，23秒）：

原因は、wkhtmltopdf が実体のない要素や印刷用 CSS の影響で“見た目は白紙だが内部的には何かがある”ページを大量に吐き出し、以前の「テキスト/画像/ベクターの有無」判定では白紙と認識できなかったことにあります。（以下略）

Ｑ（koshix）：

やはりうまくいかないのですが，dpiを増やしたり閾値を大きくするのは逆効果ではないのですか？

Ａ（ChatGPT-5 Thinking，32秒）：

ご指摘のとおり、「DPIを上げる」「閾値（white_ratio）を大きくする」は白紙判定を“厳しく”する方向なので、見えない微小ゴミ（細い罫線・1pxの影・アンチエイリアス・不可視要素のにじみ）を拾ってしまい、白紙とみなせなくなる＝逆効果になりがちです。（以下略）

Ｑ（koshix）：

だいぶよくなりました。ところが，1ページで収まらない場合に，ページ末尾の「前の投稿」で過去のページを辿る必要があるのですが，ページ末尾の「次の投稿」の方の未来のページを辿ってそれを2ページ目として採用している場合が見受けられます。なんとかなりませんか。

Ａ（ChatGPT-5 Thinking，28秒）：

了解です。2ページ目は必ず「前の投稿（= Older posts = 過去方向）」だけを辿るようにロジックを強化しました。（以下略）

Ｑ（koshix）：

常に前の投稿へを参照するようになっていませんか。目標月の1日までが1ページ内に収まっていれば，前の投稿へのリンクを辿る必要がない場合もあるのですけど。

Ａ（ChatGPT-5 Thinking，19秒）：

助かりました。ご指摘の通り、「1ページ目にその月の1日が含まれている場合は“前の投稿”を辿らない」条件を厳密に入れました。

・・・以下延々と別のエラーコードの修正で格闘を続けた・・・

・・・2020/06 がうまくダウンロードできない状態が続く・・・

Ｑ（koshix）：

(venv) koshi@mba2020 ~ % ./blgpdf 202006 -v

 File "/Users/koshi/./blgpdf", line 248

 dil = ( ^ 

SyntaxError: '(' was never closed

Ａ（ChatGPT-5 Thinking，17秒）：

ごめん、私の括弧ミスでした（dil = ( 行）。膨張処理のところをシンプルに書き直して、構文エラーを解消した完全版を置いておきます。これに差し替えてください。

・・・結局 2020/06 の問題の方は解決しなかった・・・

・・・ChatGPTでも単純なプログラムのミスを犯すのだった・・・

P. S.  10/21 brew upgrade にエラーが出ていたので，ChatGPT-5 の指示を受けながら，brew cleanup, brew update, brew upgrade, brew doctor を繰り返してエラーを潰していった。その過程でwkhtmltopdf が使えないことがわかり，代替として提示された chromium もだめだといわれた。仕方がないので再び ChaatGPT-5 に相談して上記プログラムの修正を図ったところ，brew とは関係なしに，python -m pip install playwright pymupdf requests beautifulsoup4 と python -m playwright install chromium の環境を使った修正版が使えることになった。こちらの方が数式が保持されていてうれしい。

［１］blgpdf のソースコード（2025.10.21版）

RAG入門

コンテキストエンジニアリングからの続き

RAG（Retrieval-Augmented Generation : 拡張検索生成）というのは最近よく目にする重要キーワードだ。いまひとつ理解できていなかったので，Kimi K2 に解説文を作ってもらう。この日本語があまりこなれていないので 「以下のRAGについての解説を，言葉を補って一般向けのAIテクノロジー雑誌の読みやすい解説文のような形にしてもらえませんか」と，Claude 4.に通した。

その結果を，ChatGPT-5とGemini 2.5 Flashに投げて内容や表現をチェックしてもらったら，たいへんよくできているので微修正だけで十分だといわれた。ところがそれを反映させた修正文全文を出してもらうと微妙に日本語がくずれる。しかたがないので，Claude 4.5に戻って「ですます調」から「である調」に修正したのが以下の解説文である。

RAG入門：AIが「知識を探す力」を手に入れた理由（2025.11.10 Kimi K2 →Claude4.5）

検索と生成が出会うとき、何が起こるのか

近年、ChatGPTをはじめとする大規模言語モデル（LLM）が私たちの生活に浸透してきた。これらのAIの能力は驚異的なのだが，彼らは「嘘」をつくし知識はすぐに「陳腐化」する。この根本的な弱点を克服し，AIに「知識を探す力」を与える技術として，今「RAG（Retrieval-Augmented Generation：検索拡張生成）」が世界的に注目されている。

１．RAGとは何か：AIの「図書館司書」機能

RAGを一言で表すなら，大規模言語モデル（LLM）が外部知識をリアルタイムに検索しながら回答を生成する仕組みである。

　従来のLLMは，訓練時に学習した知識だけを頼りに回答していた。しかしRAGを導入することで，LLMは必要に応じて外部のデータベースを参照し，最新かつ正確な情報に基づいた回答ができるようになる。

　その本質は，静的なパラメータ知識と動的な検索知識を分離することにある。つまりLLMは、単に「知識を持つ」だけでなく、「知識を探す」「知識を使う」という3つの役割を明確に使い分ける。

２．なぜRAGが必要なのか：3つの深刻な課題

RAGは、従来のLLMが抱える以下の3つの深刻な課題を解決するために不可欠だ。

(1) 幻覚（ハルシネーション）問題

LLMは，訓練データの統計的パターンを再現して文章を生成する。そのため，事実ではないが非常にもっともらしい内容を自信満々に語ってしまうことがある。これは「幻覚」と呼ばれ，AIの信頼性を大きく損なう問題だ。

(2) 知識の陳腐化

LLMは訓練された時点での知識しか持たない。たとえば2023年までのデータで訓練されたモデルは，2024年の出来事について正確に答えることができない。世界は日々変化しているのに，AIの知識は訓練時点で固定されてしまう。

(3) 専門性・機密性の壁

企業の内部文書や最新の研究論文など，一般に公開されていない情報は，当然ながら訓練データに含まれない。そのため，どれほど高性能なLLMでも，こうした専門的・機密的な情報にはアクセスできない。

３．RAGの基本的な仕組み：3ステップの知的循環

RAGは、以下の3つのフェーズで動作する。

(1) ステップ1：インデックス作成フェーズ

まず，参照したい文書を準備します。この文書を適切なサイズに分割（チャンキング）し，それぞれを数値ベクトルに変換（埋め込み）する。そして、これらのベクトルを検索しやすい形でデータベース（ベクトルストア）に保存する。

(2) ステップ2：検索フェーズ（リアルタイム処理）

ユーザーが質問すると，その質問もベクトルに変換される。そして，ベクトルストアから質問と最も関連性の高い文書を複数件取得する。

(3) ステップ3：生成フェーズ（リアルタイム処理）

質問と検索結果を組み合わせてLLMに入力し、最終的な回答を生成します。

この検索と生成の分離が重要です。それぞれを独立に最適化できるため、システム全体の品質を段階的に向上させることができるのです。

４．各コンポーネントの深い論理

(1) チャンキング：情報の粒度をどう決めるか

文書をどこで分割するかは，検索精度を大きく左右する。

・細かく分割しすぎる：検索精度は上がるが文脈が失われる（例：「AIの倫理」を「AI」と「倫理」に分けると意味が変わってしまう）

・大きすぎるサイズにする：文脈は保持されるがノイズが増えて検索精度が低下する。

この問題を解決するのがセマンティックチャンキングだ。これは，文章の意味的な区切れ（トピックの変わり目）を自動的に判別して分割する手法である。現代的なアプローチでは，埋め込みベクトルの類似度変化率を見て，自動的に最適な分割点を見つける。

(2) 埋め込み：言葉を幾何学的空間に配置する

埋め込みとは，単語や文章を高次元のベクトル（通常768〜1536次元）に変換する技術である。これにより，意味的な類似度を数学的に計算できるようになる。

この技術の興味深い点は，単なるキーワード一致ではなく概念的な類似性を捉えられることだ。有名な例として，「王様 - 男 + 女 = 女王」のような線形演算が可能になる。

ただし，重要な課題が残っている。埋め込みは「関連性」を計算できても，「情報の質の高さ」や「信頼性」を測ることはできない。関連しているが古い情報と，新しい重要情報を区別できない。

(3) ベクトルストア：膨大なデータから高速検索する知恵

数百件のデータなら全件検索できるが，数百万件，数十億件となると現実的ではない。

そこで登場するのがANN（近似最近接探索）アルゴリズムだ。代表的なものに以下がある：

・HNSW（階層的ナビゲーション可能な小世界グラフ）：グラフベースで高速かつ高精度

・IVF（転置ファイルインデックス）：クラスタリングベースでメモリ効率が良い

これらのアルゴリズムは，正確な最近接を諦めて速度を獲得するという実用主義的なアプローチである。これは「完璧を諦め，実用性を獲得する」という現実的な選択の表れといえる。

５．検索精度を高める進化形テクニック

(1) ハイブリッド検索：2つの検索手法の融合

単純なベクトル検索だけでは不十分なケースがあります。そこで，ベクトル検索とキーワード検索（BM25）を統合するハイブリッド検索が用いられる。

これが有効な理由は，埋め込みが捉えきれない固有名詞や数値をキーワード検索がカバーできるためだ。複数の検索結果は，RRF（逆順位融合）という数理的手法で統合される。

(2) クエリ拡張：質問を賢く分解する

LLMが質問を補完・分解することで，検索精度を向上させる。

例：「RAGの課題」という質問を以下のように展開

「RAGの精度に関する課題」

「RAGの速度に関する課題」

「RAGのコストに関する課題」

(3) 再ランキング：広く探して深く選ぶ

初回検索で100件程度を広く取得し，別のモデルで再評価して5件程度に絞り込む。これは，軽量モデルで広く探索し，重量モデルで深く選別する賢い分業である。

６．高度なRAG：アーキテクチャの進化

(1) 自己RAG：AIが自分の無知を知る

モデルが自ら判断して，必要なときだけ検索を実行する。検索が不要な場合はスキップすることで，効率性を高める。

これは，LLMが「自分の無知を自覚する」メタ認知を獲得する第一歩といえる。

(2) リカーシブRAG：多層的な推論

検索結果を踏まえてさらに検索を繰り返し，多層的な推論を行なう。これは，人間が調べ物をするときに「新しいキーワードを見つけてさらに調べる」という行為を自動化したものだ。

(3) エージェント型RAG：計画・実行・検証のサイクル

複数のツール（検索、計算、API呼び出し）を使い分ける自律型システムである。RAGが単なる「検索+生成」から，「計画+実行+検証」の循環へと進化する。

７．実装のベストプラクティス

(1) 検索品質の評価

単純な正解率ではなく，MRR（平均逆順位）やnDCG（正規化割引累積利得）を使う。これらは「役立つ文書が検索結果の上位に来ているか」を測る指標だ。

(2) プロンプト設計の哲学

「検索結果をそのまま答えてください」という指示は効果が低いことが分かっている。代わりに，以下のような指示が有効である：

・以下の文書を参考に、質問に答えてください。

・文書が不十分な場合は「情報不足」と答えてください。

・文書と矛盾しない範囲で、論理的に推論してください。

この指示により，検索結果の単純な再現ではなく，検索結果の統合を促すことができ，幻覚を抑制できる。

８．RAGの限界と本質的な課題

(1) 限界1：検索の失敗は回復不能

検索が失敗したら，どれほど強力なLLMでもそのミスを修正できない。これは「ガベージイン、ガベージアウト」（ゴミを入れればゴミが出る）の原則そのものだ。

(2) 限界2：文脈長の制約

検索結果をすべてLLMに入力できるわけではない。トークン数の制限という物理的な壁が常に存在する。

(3) 限界3：情報の整合性

複数の文書が矛盾している場合，どの情報を信じるべきかという判断基準が不明確である。これは「誰を信じるか」という根本的な問題である。

本質的な緊張関係

RAGは「検索の精度」と「生成の創造性」の間に立つ技術である。検索に依存しすぎると応答が硬直的になり，生成に任せすぎると幻覚が増える。この緊張関係をどうバランスさせるかが，RAGシステム設計の醍醐味であり，永遠の課題でもある。

９．今後の展望：RAGはどこへ向かうのか

(1) マルチモーダルRAG

テキストだけでなく，画像，音声，動画の埋め込みを統合し，同一のベクトル空間で検索可能にする技術が開発されている。

(2) 個人化RAG

ユーザーの履歴やプロフィールを埋め込みに組み込み，検索自体を個人化する。同じ質問でも，ユーザーによって異なる最適な回答を提供できる。

(3) 学習型RAG

検索結果の良し悪しをフィードバックループで学習し，検索アルゴリズム自体を最適化していく。

究極の形：「RAGなきRAG」

将来的には，LLMに外部記憶を直接接続し，検索が内部的なプロセスになる可能性がある。現在のRAGは，そこへ至る中間的なアーキテクチャなのかもしれない。

１０．まとめ：RAGが体現する「実用主義の勝利」

RAGは，「知識の所在を分離する」という，計算機科学における永遠のテーマの一例だ。CPUとメモリを分離したのと同様に，言語能力と知識ベースを分離したアーキテクチャといえる。

その価値は以下の点にあります：

・動的性：常に最新の情報にアクセスできる

・専門性：特定ドメインの知識を簡単に追加できる

・効率性：巨大なモデルを再訓練する必要がない

最終的な洞察

RAGの真の意味は，単に「LLMの知識を補う」ことではない。「LLMに知識の所在を教え，検索という行為を通じて思考を深める力を与える」ことにある。

これは単なる技術的なアップデートではなく，AIシステムの「知的自立性」を高める哲学的な転換なのだ。

完璧ではないが，うまく動く。理論的に美しいが，現実にはトレードオフが埋め尽くす。まさに，RAGは「実用主義の勝利」を体現しているアーキテクチャだといえる。

この技術は今もなお進化を続けている。RAGを理解することは，これからのAI時代を読み解く重要な鍵となるはずである。

 

図：RAGの仕組み（岡本耕太郎MathematicaRAG実装から引用）

コンテキストエンジニアリング

生成ＡＩの明日からの続き

３年前に生成AI（LLM）が登場してしばらくの間は，プロンプトエンジニアリングがはやっていた。いまでもよく見かけるが基本機能が高まるとともに面倒なのであまり話題にならなくなった。

以下のコンテキストエンジニアリングもプロンプトエンジニアリングの延長線上で，プロンプトの構造化として話題になっていたが，言語化されることで再照射されている。YAMLも神田敏晶さんが半年以上前から言及していた。それでも面倒なので一般大衆にとってはまた同じようなことになりそうだ。

最初，ChatGPTに定義を聞いた。答えを受けて更問いしたところ，実装済みというちょっと驚く結果がでた。ところが答えの定義と説明がいまいちだったので，Gemini, Claude, Grok Kimiなどに聞いて比較した。Claudeはしょぼかったので除外。残り4つの結果をテキストファイルにして Geminiに評価比較させたところ，Kimi→ChatGPT→Grok→Gemini の順位になった。Geminiは自分をえこひいきしない。

Ｑ（koshix）：

コンテキストエンジニアリングとは何ですか。

Ａ（Kimi K2）：

コンテキストエンジニアリングとは、AIエージェント（特に大規模言語モデル）があるタスクを解決するために必要なすべての文脈情報を収集・設計・管理する技術です。従来の「プロンプトエンジニアリング」が単一の指示文に焦点を当てるのに対し、コンテキストエンジニアリングはAIが「見える世界」全体を構築することを目的とします。

１．定義と背景

Gartnerはコンテキストエンジニアリングを「AIシステムが意図を理解し、文脈に沿った成果を生み出せるように、関連データ、ワークフロー、環境を設計・構築すること」と定義しています。Anthropicも同様に、これを「LLMが推論時に参照するトークンの集合（コンテキスト）を最適化する技術」として位置づけ、プロンプトエンジニアリングの自然な進化形であると説明しています。

生成AIの応用が単発の質問応答から、複数ターンにわたる自律的エージェントへと移行する中、AIの成功・失敗を分ける鍵は「モデルの性能」よりも「与えられたコンテキストの質」になりました。多くのエージェント失敗は「モデル失敗」ではなく「コンテキスト失敗」に起因するとの指摘もあります。

２．コンテキストの構成要素

コンテキストエンジニアリングが管理する「文脈」には、以下の要素が含まれます：

要素 ｜　説明 ｜　具体例

・システムプロンプト / 指示 ｜　AIの基本的な振る舞いや人格を定義する初期設定 ｜　「あなたは親切なカスタマーサポートAIです。常に丁寧に、かつ簡潔に答えてください」

・ユーザープロンプト ｜　ユーザーからの即時の要求 ｜　「明日の午後3時以降で空いている時間を教えて」

・状態・履歴（短期記憶） ｜　会話の流れや直近のやり取り ｜　ユーザーが過去に「平日は午前中は忙しい」と言っていた情報

・長期記憶 ｜　会話を超えて持続する知識（ユーザーの好み、過去のプロジェクト概要など） ｜　ユーザーが「コーヒーはブラックが好き」という情報を記憶

・検索情報（RAG） ｜　外部データベースやAPIから取得した最新・ドメイン特化情報 ｜　会社の最新製品カタログ、FAQドキュメント、社内規則

・利用可能なツール ｜　AIが実行可能な関数やAPI（在庫確認、メール送信、カレンダー操作など） ｜　check_calendar(), send_email() などの関数定義

・構造化出力 ｜　AIの応答形式の指定（JSON、XML、テーブルなど） ｜　「回答は必ずJSON形式で返し、「available_slots」キーに時間帯の配列を入れてください」

３．プロンプトエンジニアリングとの違い

・観点 ｜　プロンプトエンジニアリング ｜　コンテキストエンジニアリング

・焦点 ｜　単一の指示文（プロンプト）の作成 ｜　AIが参照する全体の文脈の設計・管理

・範囲 ｜　静的、1回限りのテキスト ｜　動的、継続的に進化するシステム

・目標 ｜　特定の応答を得ること ｜　一貫した高性能を複数セッションで維持すること

・技術要素 ｜　フューショット、CoT、プロンプト構造 ｜　RAG、長期/短期記憶管理、ツール統合、コンテキスト最適化

・捉え方 ｜　アート（表現の巧みさ） ｜　サイエンス（情報ロジスティクスの最適化）

簡単に言えば、プロンプトエンジニアリングは「AIに何を言うか」に注力するのに対し、コンテキストエンジニアリングは「AIが何を知っていて、何ができるか」を設計します。

４．なぜ必要なのか

(1) 文脈ウィンドウの限界

LLMの処理可能なトークン数には上限があります。無制限に情報を詰め込めないため、何を入れ、何を省くかの選択と最適化が必要になります。これは「情報ロジスティクス」の問題として捉えられます。

(2) 単なるプロンプトでは不十分

複雑な現実世界のタスク（例：顧客サポート、調査、予定調整）では、単に「賢く振る舞え」と指示するだけでは不十分です。AIは実際にカレンダーにアクセスできたり、過去の対話を覚えていたり、最新の社内規則を知っていたりする必要があります。

(3) エージェントの失敗の大半はコンテキスト失敗

AIエージェントが失敗する主な原因は、モデルが賢くないことよりも、必要な情報が不足していたり、誤ったタイミングで提供されたり、不適切な形式で提示されたりするためです。

５．具体例：予定調整エージェント

悪い例（コンテキスト不足）：

・ユーザー：「明日、簡単な打ち合わせの時間はありますか？」

・AI：「ありがとうございます。明日は大丈夫です。何時ごろがご希望ですか？」

→ カレンダー情報がないため、実際は午後3時から4時まで空いているのに、役立たない返答

良い例（適切なコンテキスト）：

・提供されたコンテキスト：カレンダーAPIから取得した明日のスケジュール、過去のメールで「平日の午前中は忙しい」と記載された情報、連絡先リスト、メール送信ツール

・AI：「こんにちは！申し訳ありません、明日はスケジュールが一日中詰まっております。木曜の午前中なら空いていますが、いかがでしょうか？招待を送っておいたので、ご都合をお聞かせください」

→ 実際の状況を理解し、代替案を提示して招待も送信する実用的な応答

６．実践的なアプローチ

コンテキストエンジニアリングは3つの基本コンポーネントから構成されます：

(1) コンテキストの取得・生成

・外部知識の検索（RAG）

・動的なコンテキストアセンブリ（優先度付け、テンプレート化）

・自動プロンプト生成

(2) コンテキスト処理

・情報の言語化（データをテキストに変換）

・構造化データの統合

・要約と圧縮

(3) コンテキスト管理

・長期/短期記憶の設計

・コンテキストウインドウの最適化

・状態の継続的な更新

７．まとめ

コンテキストエンジニアリングは、AIエージェント開発の新たな中心的スキルとして台頭しています。単に「魔法のプロンプト」を探すのではなく、ビジネス目的を理解し、AIがタスクを達成するために必要な情報とツールを適切な形式とタイミングで提供する設計が成功の鍵を握ります。

企業においては、コンテキストエンジニアリングを戦略的優先事項とし、専門チームを設置してデータ統合、記憶管理、ツール連携を体系的に行うことが推奨されています。

Ｑ（koshix）：

あなたはコンテキストエンジニアリングを実装していますか。あるいはそれに相当する機能を仮想的に実現できますか。そのために私がすべきことはありますか。

Ａ（ChatGPT-5）：

短く前提をそろえます。

ここで言う「コンテキストエンジニアリング（CE）」は、会話や作業の“前提・制約・根拠・目的・出力仕様”を設計して、AIが一貫して適切に動くようにする実務です。私はその中核をすでに実装しており、足りない部分は仮想的（運用設計）に補完できます。以下に「私ができること」と「あなたが今日からやると効果が最大化すること」を、手順化して示します。

１．私がすでに実装しているCE要素

(1) 長短期コンテキスト管理

・直近の会話履歴を前提化／矛盾検出。

・必要に応じて長期記憶（“覚えて”と指示があれば保存）を使い分け。

(2) 外部知識の取り込み（軽量RAG）

・あなたのアップロード文書を根拠として検索・引用。

・公開Webはその都度ブラウズし、主要主張には出典を付す。

(3) 目的駆動の出力制御

・タスク目的→評価基準→出力フォーマット（表・コード・PPTX 等）を明示して動く。

・制約（語調、分量、数式有無、図示の有無）も“仕様”として扱う。

(4) 品質ガードレール

・推測は推測と明示／数値は可能な限り計算ツールで検算／不確実は保留・要検証で区別。

(5) ワークスペース仮想化

・プロジェクトごとに“コンテキスト・パック”を用意し、毎回の冒頭に読み込む運用で擬似的な永続コンテキストを実現。

２．いまからできる最短ルート（あなた側の5ステップ）

Step 1｜ゴール宣言

タスクの目的・成功条件・締め切り・想定読者を1ブロックで宣言。

Step 2｜ソース束ね（Evidence Pack）

根拠文書をまとめて提示（URLでも可）。重要度や信頼度、使ってよい／ダメを明記。

Step 3｜出力仕様

最終成果物の型（要約/表/図/コード/PPTX/原稿）、分量、スタイル、引用方針、図表要件。

Step 4｜制約・優先度

時間・正確性・網羅性・新規性などの優先度（例：正確性>網羅性>速度）。

Step 5｜長期設定（任意）

次回以降も効く“恒常設定”を覚えさせたい場合は「覚えて：〜」と明示。

３．そのまま貼れる「セッション・キックオフ」テンプレ

（毎回の最初にコピペすると、CE効果が一気に安定します）

# GOAL

目的：＿＿＿＿

成功条件：＿＿＿＿

想定読者/用途：＿＿＿＿

締め切り：＿＿＿＿

# EVIDENCE PACK

一次資料：＿＿＿＿（信頼度A）

補助資料：＿＿＿＿（信頼度B）

使ってはダメ：＿＿＿＿

# OUTPUT SPEC

形式：＿＿＿＿（例：Markdown要約＋表1枚／Pythonコード／PPTX5枚）

分量/トーン：＿＿＿＿

図表/数式：＿＿＿＿

引用方針：＿＿＿＿（主要主張には出典）

# CONSTRAINTS & PRIORITIES

優先度：＿＿＿＿（例：正確性>再現性>速度）

除外事項：＿＿＿＿

前提の更新：＿＿＿＿（前回との差分があれば）

# OPEN QUESTIONS（不確実点）

1) ＿＿＿＿

2) ＿＿＿＿

４．永続利用向け「コンテキスト・パック（YAML）」雛形

（プロジェクトごとに1つ作って、冒頭に貼る）

project: <プロジェクト名>

goals:

  - <主要ゴール>

audience: <対象>

success_criteria:

  - <測定可能 or チェックリスト>

sources:

  trusted:

    - {title: <>, link: <>, notes: <>, must_use: true}

  auxiliary:

    - {title: <>, link: <>, notes: <>}

  banned:

    - {title: <>, reason: <>}

output:

  type: <summary|report|code|slides|diagram>

  length: <e.g., 1200-1500 words>

  style: <tech-brief | academic | executive>

  visuals: <tables:true, charts:true, equations:true>

quality:

  priorities: [accuracy, transparency, reproducibility]

  citation: required_for_key_claims

guardrails:

  - separate facts/inference

  - flag low-confidence

update_cadence: <per_session | weekly | milestone_based>

５．すぐに使える「あなた向け」プリセット例（3本）

必要ならこの3本をそのまま使ってください。どれか一つを貼るだけで、その回は最適化して動きます。

A) AIシステム研究（批判的レビュー）

・目的：新規AI論文／製品の技術的妥当性と限界、代替案を整理

・成果物：根拠つき要約（800–1200字）＋比較表（3列）＋リスク項目

・優先度：正確性>網羅性>速度、主要主張は出典必須

B) 文化史・神道研究（史料基づく解説）

・目的：史料（原典）と二次文献を峻別し、語義・時代背景を整理

・成果物：概念マップ（箇条書き最小）、典拠付き本文

・優先度：典拠厳格>読みやすさ>分量

C) 旅行計画／冊子化（実務アウトプット）

・目的：日程・移動・開館時間を確定し、冊子用レイアウト草案を生成

・成果物：日別表＋要所解説（200字/地点）＋PDF化しやすい構成案

・優先度：実用性>網羅性>散文の美しさ

６．長期記憶の使い方（任意）

「覚えて：____」と書けば、以後のセッションで前提化できます。

例：

・覚えて：主要主張には必ず出典を付ける

・覚えて：数値は計算ツールで検算する

・覚えて：日本語で、表はMarkdown

※私から勝手には保存しません。保存指示があった項目だけ反映します。

７．まとめ（要点）

・私はCEの主要要素（前提設計・根拠取り込み・出力制御・品質ガード）を実装済み。

・永続化が必要な部分は「コンテキスト・パック」を冒頭投入する運用で仮想的に実現可能。

・あなたは上記テンプレのStep 1–5を貼るだけで、精度・再現性・スピードが一段上がります。

この方針で、次の案件からすぐ走らせます。まず扱いたいテーマを一つ選び、上のセッション・キックオフを埋めて投げてください。こちらで“文脈→工程→成果物”に落とし込みます。

図：コンテキストエンジニアリングの構成要素（[2]から引用）

［１］コンテキストエンジニアリングとは？（アイサカ創太）

［２］Context Engineeringについて（farstep）

［３］コンテキストエンジニアリングとは？ （ソフトバンク）

［４］コンテキストエンジニアリングとは？（坂本将磨）

［５］AIを賢く動かすのは「指示力」ではなく「文脈設計力」（吉岡裕樹）

元素周期表3D

物理の日からの続き

橋本大也さんといえば，読書家であり海外の本を原語で読み漁っていた。ところが最近では，AIによるバイブコーディングの伝道師と化している。Claude（が一押しらしい）の周期表ウェブアプリが，たった5つのメッセージだけでできたというので追試した経緯が以下。

(1) Claudeにて

橋本さんの書いていたプロンプトはこれ。

【元素表を作って】

【各元素をクリックすると、その元素の用途の解説とイラスト（ピクトグラム）が表示されるようにして】

【詳細情報を下部ではなくてホバー表示させる。視覚効果を７つ追加】

【ホバー表示した詳細情報は音声読み上げする】

【Three.jsで回転可能な原子構造を表示する】

いちおうCaludeの画面上のインタラクティブ元素周期表はできたのだけれど，自分の環境ではどう移植すればよいかわからない。というのもThree.js という3Dライブラリを使う必要があるからだ。仕方がないので，ChatGPTに相談することにした。

(2) ChatGPTにて

最初はThree.jsを含む環境設定方法を聞いたのだけれど，自分が最新のウェブアプリ開発について何もわかっていない素人なので，答えを聞いてもチンプンカンプンである。そこで，Claudeの作ったWebアプリコードを直接入力して，自分のローカル環境で実行したいとお願いした。最初からそうすれば良かった。以下の段取りを指示された。

・Next.jsプロジェクトを作る

　% npx create-next-app@latest periodic-table-app

・Tree.jsをインストールする

　% cd periodic-table-app

　% npm install three

・コンポーネントファイルを作成（nanoは単なるエディタ）

　% mkdir -p app/components

　　nano app/components/PeriodicTable.tsx

・トップページから呼び出すように設定

　% app/page.tsx を編集（Reactコンポーネントの拡張子らしい）

・開発サーバを起動して確認

　% npm run dev

　⇒ http://localhost:3000 でアプリが立ち上がる。

Ｑ（koshix）：

ありがとうございます。 node も npm もbrew でインストールされていました。 自分は初心者であり，htmlとかcssとかjavascriptは何となくわかりますが， node, npm, mpx, Next.js + React + TypeScript + Tailwind + Three.js が何を意味しているかを概念的に把握できていません。申し訳ないのですが，よくわかるようにこれらの要点や注意点を解説していただけませんか。

Ａ（ChatGPT-5）：

（長々と説明された後）

あなたのための短いアナロジー

・HTML → 家の骨組み

・CSS → 壁紙・装飾

・JavaScript → 家の仕掛け（自動ドア・照明）

・Node.js → 家を作る工場のようなもの

・npm → 工場で使う工具や材料（React / Next / Three のパッケージ店）

・React → 家の“部品”をモジュール化して大量生産

・Next.js → 部品を組み合わせて「街」を作るシステム

・Tailwind → スタイルを一瞬で貼る装飾セット

・Three.js → 3D ホームシアター設備

わかったようなわからないような。とりあえず，あれこれ相当試行錯誤してローカル環境で周期表アプリは動いた。ががが・・・さらに修正を繰り返しているうちに ⇒ 「思考が停止しました。」（私がではない，ChatGPTがである）

次の日にやり直したものの，途中で再びエンストしたまま動かない。（大丈夫か）

(3) Geminiにて

昨日までに作られた PeriodicTable.tsx，elements.ts，PeriodicTableJSON.json の３つのファイルをインプットしてやり直しをお願いした。ChatGPT-5と違ってスイスイと話が進んでいく。もしかすると，プログラミング能力についてはChatGPTよりGeminiの方が優れているのではないか。ChatGPTにあっさり断られた 元素の発見者（発見年）や存在比などにも柔軟に対応してもらえた。その上親切にも元素発見の歴史を表す周期表の動画まで紹介してくれた。

さらに，これをさくらインターネットの公開サーバに移植する方法を尋ねたところ，

・設定ファイルの変更

　% next.config.ts

・ビルド（書き出し）の実行

　% npm run build

　⇒ out フォルダにNext.js アプリを公開する際に最も簡単で確実な「静的エクスポート（Static Export）」という機能を用いた結果が生成された。

・サーバーにアップロード

　outフォルダのディレクトリ構造全体をsftpで転送すればよい。

　https://nucleus.sakura.ne.jp/atom/

に結果（正確性は保証していませんので注意してください）が得られた。橋本さんの言うように5行でOKとは行かず，足掛け2日がかりだった。しかし，生成AIがなければ，1ヶ月勉強した上の1週間仕事だろう。

図：周期表ウェブアプリの表紙

P. S. まあ，3Dの怪しい電子軌道の絵にはあまり意味がないと思うんですけど。

P. P. S. なにやら新しいグーグル検索機能が追加されたようなので試してみた。

穂積押山

国道169号線の櫟本にある中西ピーナツの東隣に和爾下神社がある。このあたりが和珥氏の本拠地だ。その南，布留の郷にある石上神宮と関係の深い物部氏とか，飛鳥の蘇我氏とかメジャーな氏はよく名前を聞くが，同じ古墳時代から奈良時代にかけての代表的な氏（うじ）である穂積氏というのは初耳だった。

天理市にあるなら歴史芸術文化村の「“穂積”の地の古墳を探る。～星塚古墳・小路遺跡と荒蒔古墳～」という歴史フォーラムに参加した。うちの近所の古墳がたくさん登場するというので楽しみにしていた。穂積氏の本拠地の１つかもね？と推定される小路遺跡，その穂積氏と関係あるかもしれない星塚古墳，すぐそばの我がマンションの敷地内にあった荒蒔古墳がメインテーマだ。

東の岩室池古墳や西の水晶塚古墳を含めてすべて，普段の朝の散歩コースの範囲内にある。これらの古墳時代後期の古墳群は30-60ｍの小さな前方後円墳（帆立貝型古墳）であり，大きな円筒埴輪，石見型埴輪に加え，家，人，馬，雞，犬など多数の形象埴輪が出土した。荒蒔古墳に至っては250ケース分の埴輪が出てきて整理に38年もかかってしまった。

穂積氏は物部氏と同祖である。継体天皇の臣であった穂積押山（6世紀前半）は，512年に百済に使わされ百済官僚として現地の哆唎国守を務めた。任那の上哆唎・下哆唎・娑陀・牟婁の四県割譲にかかわり，奈良大学の小林青樹先生によれば，越境エージェントとでも言うべき，国をまたがっての活躍をした人らしい。

P. S. なら歴史芸術文化村の文化財修復・展示棟では「“穂積”の地の古墳を探る 奈良盆地中央部の古墳群」として，実際に発掘された埴輪やその他の遺物が展示されていた。星塚古墳から出た日本最古の木製笛は，その実際の音がテープで流されていた。早く重要文化財に指定してほしい。

写真：荒蒔古墳の出土品（天理市から引用）

こっき（３）

こっき（２）からの続き

Ｑ（koshix）：

（旧ファイル kokki.html を添付）

外部サイト（"https://restcountries.com/v3.1/all"）の国旗データにアクセスできなくなりました。そこで，このサイトはつかわないことにします。flagpedia.netから国連加盟国の国旗のsvgデータを持ってきました。 250カ国ほどの国旗データはjp.svgのように，二文字の国旗コード名のsvgファイルとして flagsディレクトリ以下に格納されています。 このローカルデータを用いてもとのkokki.htmlと同等の機能を実現するhtmlファイルを作成してください。

Ａ（ChatGPT-5）：

もとの kokki.html は restcountries.com に依存して国名や地域情報を取得していましたが、今回は 外部APIを使わず、flags/xx.svg（ISO α2コード）だけで動く版に作り替えます。（以下回答略）

Ｑ（koshix）：

表示部で国記号（国記号）となっているのを，国記号（日本語の国名）になるようにしてください。

Ａ（ChatGPT-5）：

了解しました。いまのHTMLでは表示部分を「JP（日本）」のように 国記号（日本語の国名） に変更したい、ということですね。（以下回答略）

Ｑ（koshix）：

改善されていませんが。

Ａ（ChatGPT-5）：

ごめんなさい。原因は「日本語名の辞書が無いと、itNameJa() が国コードをそのまま返す」仕様のままだったことです。（以下回答略）

Ｑ（koshix）：

修正した全コードを下さい。

Ａ（ChatGPT-5）：

了解です。ご指定の「国記号（日本語の国名）」表示に修正済みの全体コードをお渡しします。外部API不要・flags/xx.svgのみで動作し、日本語名は Intl.DisplayNames で自動生成（辞書があれば優先）します。（以下回答略）

Ｑ（koshix）：

表示領域が全世界だけイキの状態です。現行の5つの地域ごとに選択することはできないのですか？

Ａ（ChatGPT-5）：

ありがとうございます。原因は、地域フィルタが「flags/regions.json が無いと無効化」される設計のままだったことです。（以下回答略＝ほぼ希望どおりのものに）

図：kokki.htmlの例

P. S. なお，その後かざはチャンは国旗への関心を失ってしまい，どの国旗ももう憶えていないらしい。チーン。

単純な計算ミス

まだまだAGIまでの道のりは遠い。のかな？ 

Ｑ（koshix）：

2つの因数分解した式のうち，2 cos (3 x + π/4) sin (5x/2 - π/4) は間違っていませんか？

Ａ（ChatGPT-5 Thinking，46秒）：

ご指摘どおり、先に示した

2 cos (3x + π/4) sin (5x -π/4)

は 誤り でした。正しくは “半分” を取り忘れており、以下のとおりです。

正しい因数分解

sin (4x) - cos x = sin (4x) - sin (π/2-x) = 2 cos {(4x}+(π/2-x)}/2 sin  {(4x}-(π/2-x)}/2 

⁡ゆえに

sin (4x) - cos x = 2 cos (3x/2 + π/4) sin (5x/2 - π/4)

 

どこで間違えたか

和積公式 

sin A - sin B = 2 cos (A+B)/2 sin (A-B)/2 の(A+B)/2を

{⁡4x + (π/2-x)}/2 = 3x/2 + π/4 とすべきところを、誤って 3x + π/4として “2 で割る” 操作を落としていました。修正後の式は恒等的に一致します。ご指摘ありがとうございました。 

Ｑ（koshix）：

あなたはときどき単純な計算ミスをすることがありますが，毎回の計算後に自分で確認のための計算を内部的に実行して（そこは表示しない）おくということはできないものでしょうか。

Ａ（ChatGPT-5 Thinking，21秒）：

はい、できます。以後、数式変形や数値計算のたびに非表示の検算を内部で走らせてからお出しします（前回の因数分解も内部検算で恒等成立を確認済みです）。

どう検算するか（内部で実施）

・二重経路確認：同じ結論に別の恒等式・導出経路で到達できるかをチェック。

・数値サンプリング：任意の点（複数）で元式と結果の差が機械誤差内（例：

10^{−12} 〜 10^{-15} ）に収まるかを確認。

・端点・特異点：零点・極値・定義域の境界など、エッジケースで整合性を確認。

・次元・符号・極限：単位（次元）整合、符号、極限挙動の整合を点検。

・丸め誤差の扱い：浮動小数の残差は許容幅を明示し、超えた場合は差し戻して再計算。

適用範囲

・代数・三角・指数対数・微積の式変形や恒等確認、行列演算、連立解、近似評価などはこの手順で検算します。

・純概念的な問い（定義・歴史・解釈）は検算の対象外ですが、典拠の確認や反例探索を代替手段として行います。

もし「検算ログも見せてほしい」場合は、可視化用に要点だけを簡潔に開示します（数値表や要約）。今後もこの運用でいきます。

本当にそうしてくれるのかどうかはよくわからない。

ブルーカラーの時代

副教科の時代からの続き

エアコン暖房の季節が来たと思ったらブレーカーが落ちて動かない。マニュアルに従ってエラーコードを調べるとU4で，自分では対応できないものだ。ジョーシンの長期補償窓口（人間を選択）に電話して状況を説明する。その後の訪問予約電話は自動音声応答だった。

サービスエンジニアの若いお兄さんは，すぐに屋外機の基盤がおかしいことを突き止めた。電動ドライバーで硬いネジをてきぱきと緩めて，パソコンのマザーボードの配線のような基盤との結線を丁寧に外す。基盤の表面はショートで焦げていた。30分ほどで全作業は完了してテスト運転も成功した。

これまでもエアコンクリーニング，水漏れ修理，200V交換，ドラム式洗濯機のパッキン交換，給湯器の修理など何度も訪問修理の技と力の人に助けられた。これらを高級乗用車並価格のAIヒューマノイドに代替するのはそう簡単ではないような気がする。

家庭内軽作業や介護支援のAIヒューマノイドにしても普通乗用車並価格で普及するには時間がかかるだろう。その一方で，ホワイトカラー（デスクワーク）のAIエージェントへの置き換えは着実に進んでいく。GAFAMの人員削減は進み，NTTは5年後に業務の半分が生成AIに代替されるとした。こうして副教科の時代が支えるブルーカラーの時代が到来している。

一方，ヒューマノイドが普及すれば，そのブルーカラーの時代にもすぐに終わりが来るという説もあるが，そうは問屋が下ろさないのではないか。我々の複雑で多様な世界を支える労働は非常に面倒な泥臭い現場の汚れ仕事の絡み合いである。安全で準定型的作業が保証される場を除くと，クリーンな環境で製造された精密機械式生命がスイスイこなせるようなしろものではないような気がしてならない。

現実の生命や事物が複雑に絡み合っている世界とそれを取り巻く物質的環境は，ホワイトカラー的な抽象世界の住人たちの手にはなかなか負えない。

写真：修理中のダイキンエアコン室外機

ヌクレオチド

学校で学んだ「知識」でも，その表層をなぞるだけで実は理解していないということがたくさんある。その散らかった「知識」の山の中に思いもかけない「発見」をすることが希にある。普段はそのよくわかっていない言葉を統計的オウムのようにつなげるだけで，理解したつもりの「知ったか会話」をすることができる。困っちゃーうーワー。

さて今回のテーマはヌクレオチド。放送大学でみかけたか。

(1) 単糖が結合（グリコシド結合）して多糖（例えばデンプン）になる。アミノ酸が結合（ペプチド結合）してタンパク質になる。ここまではよく知っているつもり。ところでヌクレオチドが結合（リン酸ジエステル結合）して核酸になる。そうか，DNA（デオキシリボ核酸）やRNA（リボ核酸）の構成単位をヌクレオチドと呼んでいたのか。

(2) ヌクレオチド＝塩基＋糖＋リン酸である。この糖はデンプンを作るブドウ糖＝グルコースのように炭素6個ではなく，炭素5個からなるリボースやデオキシリボースと呼ばれるものだ。単糖を炭素数で分類すると，3〜7個のものがあって，その代表がヘキソース（C6個）とペントース（5個）だ。

(3) リボースとデオキシリボースの違いは2'の炭素に位置につくのがOHかHかだ。デオキシリボースはde oxi なので酸素が欠けている。つまりこれまで何の気なしにつかっていたDNA=デオキシリボ核酸（デオキシリボースからなるヌクレオチドがつながってできる核酸）のデオキシは酸素が欠けているという意味だった。ガッテン！×３

(4) ところで，このRNAやDNAの構成単位であるヌクレオチドは塩基＋ペントース（リボースまたはデオキシリボース）＋リン酸だったけれど，みなさんよくご存知のATP（アデノシン３リン酸）もヌクレオチドの一種だった。RNAの構成要素であるAMPにリン酸基が2個追加されたものが，ATP = アデニン（塩基）+リボース（糖）+3リン酸というわけだ。ATPは多くの生化学反応でエネルギーを運ぶ非常に重要な分子だ。これがRNAの構成要素の親戚だとは。

(5) リボースとデオキシリボースからなるリボヌクレオチドとデオキシリボヌクレオチドは，RNAとDNAの骨格をなして，それぞれ「化学的に比較的不安定な作業用の情報坦体」と「化学的に安定して長期的な遺伝情報を保存する役割」を果たすことになる。

今日の結論：ヌクレオチドはRNAやDNAの構成要素，ATPはヌクレオチドの一種。

付録：脂質についてもモノマーがつながってポリマーになる構造はないのか聞いたところ，脂質は脂肪酸とグリセロールなどがエステル結合した複合体だけれど，多糖（デンプン等）やタンパク質や核酸と違って，モノマーがつながった鎖状構造のポリマーは作らないらしい。そのかわり複合体が疎水性相互作用などの非共有結合によって膜（二重層）構造をつくっている。

図：DNAやRNAを構成するヌクレオチドとATP

モンテ・クリスト伯

日経文化面の映画紹介，モンテ・クリスト伯が面白そうだったので観に行くことになった。奈良には上映館がなく，このあたりでは京都シネマとTOHOシネマズなんばと大阪ステーションシネマだけだ。上映時間の関係で梅田のルクア11階，大阪ステーションシネマに向かう。

前日にウェブでチェックすると120席の1/5ほどが埋っていた。珍しいことだ。油断したまま現地に着くと95%くらい売れてしまっていた。普段は空席が95%の映画ばかりなのでビックリだ。平日の午後，暇なじいさんばあさんばかりが映画館に集結している。

フランスで製作された大作映画だ。映画はやじゃり発祥の地のフランス語がよい？導入部では主人公が22歳なのに関係者がみな老け顔なので，ちょっと微妙だった。物語は投獄され脱出したの14年後に展開するので仕方がないか。小学生の頃に図書館で借りた巌窟王を読んだだけなのだが，牢獄からの脱出のあたりは微かに印象にある。

原作は岩波文庫で7冊分の長編であり，3時間に押さえるためにかなり脚色されているはずだ。登場人物も整理されてわかりやすい。モンテクリスト伯側のエデが何者かわからないままに見ていた。説明を見落としたかと思ったが，後半の映画の中で説明がありました。

モンテクリスト伯をモチーフにしたアルフレッド・ベスター（1913-1987）のSF小説が虎よ虎よ！。世界SF全集で初読したときは，文字と記号の大胆な表現にビックリした。この作品が素晴らしかったことを顕彰するためヒューゴー賞が発足したと間違った俗説記憶を持っていたが，このたびChatGPTに確認すると年代的その他のファクトで否定された。なお，第1回のヒューゴー賞受賞作がベスターの分解された男だったのは事実だ。

図：モンテ・クリスト伯のポスターを引用

P. S.  虎よ虎よ！は1956年に英国で出版されたときのタイトル。ウィリアム・ブレイクの詩 The Tyger  から来ている。米国ではその文学的な空気が嫌われ，Stars My Destination と変更されて，ギャラクシー・サイエンス・フィクションに連載された。