　　　　On a Thread of the Web: プログラミング

ラベル プログラミング の投稿を表示しています。すべての投稿を表示

2026年6月4日木曜日

MediaWiki（４）

Ｑ（koshix）：
日本語Wikipediaの物理学者記事にあるテンプレートやモジュールのうちで主要なものを，自分のMediaWikiサイト，Fisica Wiki に移植するプロジェクトの件です。
codexにお願いして，
koshi@mba2020 ~ % ls -al jawiki-template-test
total 208
drwxr-xr-x 17 koshi staff 544 5月 1 13:40 .
drwxr-x---+ 131 koshi staff 4192 5月 5 16:40 ..
-rw-r--r-- 1 koshi staff 464 5月 1 11:17 articles.txt
-rw-r--r-- 1 koshi staff 749 5月 1 13:41 core_export_pages.txt
-rw-r--r-- 1 koshi staff 659 5月 1 13:02 export_pages.txt
-rw-r--r-- 1 koshi staff 7912 5月 1 12:58 extract_template_dependencies.py
-rw-r--r-- 1 koshi staff 8317 5月 1 11:29 extract_templates.py
-rw-r--r-- 1 koshi staff 1614 5月 1 13:01 make_export_pages.py
-rw-r--r-- 1 koshi staff 1956 5月 1 12:53 make_module_list.py
-rw-r--r-- 1 koshi staff 3488 5月 1 13:33 make_template_export_pages.py
-rw-r--r-- 1 koshi staff 307 5月 1 12:59 modules_needed.txt
-rw-r--r-- 1 koshi staff 2866 5月 1 13:08 README.md
-rw-r--r-- 1 koshi staff 17 4月 30 22:37 requirements.txt
-rw-r--r-- 1 koshi staff 1345 5月 1 12:19 template_dependencies.csv
-rw-r--r-- 1 koshi staff 2284 5月 1 13:35 template_pages.txt
-rw-r--r-- 1 koshi staff 18146 5月 1 11:54 template_usage.csv

こんな状況になっています。自分がなにをしたか，してもらったかが，よくわからなくなっているので，状況を整理して，現在の進行状況がどうなっているか，これからどうすればいいか，を教えてください。必要があれば，それぞれのファイルや現在のFisica Wikiの内容を確認してお知らせすることが出来ます。どうぞよろしくお願いいたします。

Ａ（ChatGPT）：
状況はかなり整理できます。結論から言うと、いまの jawiki-template-test は、日本語Wikipediaの物理学者記事を材料にして、Fisica Wikiへ移植すべきテンプレート・モジュールの候補リストを作るための作業ディレクトリになっています。

ただし、ここにあるファイルだけを見るかぎり、これはまだ「移植そのもの」ではなく、主に次の段階まで進んだ状態です。

・第1段階：物理学者記事を調べる
・第2段階：それらの記事で使われているテンプレートを抽出する
・第3段階：そのテンプレート群に必要な関連テンプレート・モジュールを推定する
・第4段階：日本語Wikipediaの特別:データ書き出しに渡すページ一覧を作る

ここまでは、かなり進んでいます。一方で、Fisica Wiki側に何が実際に取り込まれていて、何がまだ赤リンク・Luaエラー・TemplateStylesエラーになっているかは、この一覧だけではまだ確定できません。

ファイルごとの意味は、おそらく次のようになります。

articles.txt は、調査対象にした物理学者の記事名リストです。たとえば「ハンス・ベーテ」「ニールス・ボーア」「湯川秀樹」のような記事名が入っているはずです。ここが出発点です。

extract_templates.py は、articles.txt にある記事を日本語Wikipediaから取得して、それぞれの記事中に現れるテンプレートを抽出するスクリプトだと思われます。その結果が template_usage.csv です。

template_usage.csv は、どの記事でどのテンプレートが使われているかを記録した表です。Fisica Wikiに物理学者記事を移すとき、どのテンプレートが頻出するかを見るための中心的な資料です。

extract_template_dependencies.py は、テンプレートがさらに別のテンプレートやモジュールを呼んでいないかを調べるスクリプトです。Wikipediaテンプレートは単体では動かず、内部で {{Ifempty}} や {{Citation}} や #invoke:Citation/CS1 などを呼ぶため、この依存関係の抽出が重要です。

template_dependencies.csv は、その依存関係の表です。たとえば「テンプレート:Cite web はモジュール:Citation/CS1 を必要とする」といった情報が入っているはずです。

make_module_list.py は、依存関係の中からモジュール: 名前空間のものだけを抜き出すためのスクリプトでしょう。

modules_needed.txt は、必要と推定されたLuaモジュール一覧です。サイズが307バイトなので、かなり小さいリストです。過去の経緯から考えると、モジュール:Citation/CS1 系、モジュール:Arguments、モジュール:If empty、モジュール:String、モジュール:TableTools、モジュール:Yesno あたりが入っている可能性があります。

make_template_export_pages.py は、必要なテンプレートを日本語Wikipediaの「特別:データ書き出し」に渡しやすいページ名リストへ整形するスクリプトだと思われます。

template_pages.txt は、移植候補のテンプレートページ一覧です。サイズが2284バイトなので、ある程度の数があります。

make_export_pages.py は、テンプレートとモジュールなどを合わせて、最終的なエクスポート対象ページ一覧を作るスクリプトでしょう。

export_pages.txt は、最初に作ったエクスポート用ページリストだと思われます。

core_export_pages.txt は、より絞り込んだ「主要部分だけ」のエクスポート用ページリストだと思われます。名前から見ると、全候補ではなく、Fisica Wikiでまず動かすべき中核テンプレート・モジュールをまとめたものです。

README.md は、Codexが作った作業説明書です。ここに実行手順や前提が書かれているはずです。まず読むべきファイルです。

requirements.txt はPythonスクリプトに必要なライブラリです。17バイトなので、たぶん requests など最小限だけでしょう。

現時点の進行状況を、作業フェーズで言うとこうです。

１．まず、分析用ツール群は作られている。これはすでに達成されています。extract_templates.py、extract_template_dependencies.py、make_export_pages.py などがそろっているので、Codexは「日本語Wikipediaからテンプレート使用状況を調べ、移植候補リストを作る」ための小さな道具立てを用意したことになります。

２．次に、物理学者記事に使われるテンプレート候補も抽出済みです。template_usage.csv、template_dependencies.csv、template_pages.txt、modules_needed.txt が存在するので、少なくとも一度は処理が走っています。

３．さらに、日本語WikipediaからXMLエクスポートするためのページ一覧も作成済みです。export_pages.txt と core_export_pages.txt があるので、次の作業はこれを使って日本語Wikipediaの「特別:データ書き出し」からXMLを取得し、Fisica Wikiの「特別:データ取り込み」で取り込むことになります。

（中略）

これからやるべきことは、いきなり再インポートではなく、まず「現在地の棚卸し」です。
まずMac側で、次のコマンドを実行して内容を確認してください。

（後略）

以下，指示された通りに進めていく。長いモジュールやテンプレートのリストを提示して，これがどうなっているかチェックせよといわれたが，手動だとやってられない。相談したところ，MediaWiki API を使えば良いといわれたので，以下，ChatGPTがその都度作ってくれる，APIをたたいてチェックするpythonコードをコマンドラインで入力し，その出力結果をChatGPTの対話画面に貼付ける，という操作を延々と繰り返す。その前提として，check_fisica_pages.pyと，check_fisica_rendered.py というコードを準備してくれた。

一例を見せると下記のようなものである。

python - <<'PY'
import requests

API_URL = "https://nucleus.sakura.ne.jp/wiki/api.php"

text = """
これは仮リンクのテストです。

{{仮リンク|Test Person|en|Test person}}
"""

r = requests.get(API_URL, params={
"action": "parse",
"format": "json",
"contentmodel": "wikitext",
"text": text,
"prop": "text",
"formatversion": "2",
}, timeout=30)

data = r.json()
html = data.get("parse", {}).get("text", "")
print(html[:3000])
PY

その後，レオ・シラードとかハンス・ベーテとかでチェックしたが，表示がおかしいのは.cssファイルのせいだということになり，この簡易版を適当に作ってもらって現在に至る。プログラミングのプロセスが，過去とは完全に違うスタイルになってしまう。

2026年5月25日月曜日

OpenAI Codex

図：OpenAI Codexの起動画面

かつてClaude Codeを絶賛していた菅野完が，Codexに乗り換えるというので，さっそく追随してみた。AIによるプログラム開発支援モードである。

まずは，brew install codex でインストールしたところ，既にnpmで入っていたものとぶつかってしまう（どこかで見た風景）。仕方がないので，アンインストールしてから，brew install --cask codex でOK。ターミナルで，codexとすると，図の実行画面になる。

macOSにはWebインターフェースのcodexアプリ版もあるのだけれど，ChatGPTには，CLI版を使うようにアドバイスされた。Claude CodeとCodexの違いも聞いたのだが，Claude Codeは親切な対話型でコードのレベルも高くコンテキストウィンドウも大きい。しかし，トークンが嵩みコストが高すぎるのがネックだ。Codexは自動型でどんどん進んでいくが（ちょっと速すぎてこわかった），トークンコストは低いし，OpenAI Plusで無料で利用できる部分もある。

実行例として，日本語Wikipediaからテンプレートとモジュールと抽出するコードで試した。

Codex CLIのコマンドラインでの結果をClaudeでまとめてもらったものが，以下である。

Ａ（Claude）：

OpenAI Codex（GPT-5.5搭載）を使用して、日本語版Wikipediaからテンプレート使用状況を抽出するCLIツールを作成した過程をまとめました。

１．開発環境の準備と要件定義

まずはプロジェクト用のディレクトリを作成し、仮想環境を有効化してCodexを起動します。

```bash

source ~/myenv/bin/activate

pwd

# /Users/koshi/jawiki-template-test

codex

```

依頼内容：

・Wikipedia APIからwikitextを取得し、テンプレート名と出現回数をCSV出力するPythonツール。

・ `extract_templates.py`, `articles.txt`, `requirements.txt`, `README.md` の4ファイルを作成。

２．実装フェーズ（一括生成）

Codexがリポジトリ内を確認し、既存ファイルがないことを把握した上で、一気に4つのファイルを生成しました。

> **Codexの判断:**

> 「フォルダ内には既存ファイルがないようです。API取得、簡易テンプレート抽出、CSV出力、READMEの最小構成で実装します。」

メインロジックである `extract_templates.py` では、MediaWiki APIへのリクエスト処理が実装されました。

```python

# APIリクエスト部分の引用

params = {

"action": "query",

"format": "json",

"prop": "revisions",

"titles": title,

"rvprop": "content",

"rvslots": "main",

"redirects": "1",

}

```

３．ユニットテストと動作検証

ファイル生成後、Codexは自律的に「コードが動くか」のチェックを開始します。

・構文チェック： `python -m py_compile` でエラーがないか確認。

・ロジック検証： ネットワークを使わずに、正規表現によるテンプレート抽出が正しく機能するかテスト。

```bash

# 抽出ロジックのテスト実行

python -c "from extract_templates import extract_template_names; \

print(extract_template_names('{{Infobox|x={{small|a}}}} text {{テンプレート:出典の明記}}'))"

# 出力結果: ['Infobox', 'small', '出典の明記']

```

４．ネットワーク接続テスト（実機確認）

最後に、実際にWikipediaのサーバーへ接続して記事（「日本」「東京」）のデータを取得できるかテストします。一度ネットワークエラーが出たものの、権限を承認して再実行。

```bash

python extract_templates.py --input articles.txt --output template_usage.csv

# Fetching: 日本

# Fetching: 東京

# Wrote template_usage.csv

```

５．仕上げ（クリーンアップ）

動作確認のために生成された一時ファイル（`template_usage.csv` や `__pycache__`）を、Codexが「依頼外のファイルである」と判断して自動的に削除しました。

> **Codexの配慮:**

> 「動作確認で CSV が生成されましたが、依頼された作成対象は4ファイルなので、成果物サンプルは残さず削除しておきます。」

まとめ

最新のGPT-5.5モデルを搭載したCodexは、単にコードを書くだけでなく、「環境確認 → 実装 → テスト → 修正 → 掃除」という一連のエンジニアリング工程を自律的に完遂しました。

最終的に、指定通りの4ファイルが揃ったクリーンな状態で作業完了となりました。

2026年4月21日火曜日

ヒマワリ

ひまわりからの続き

図１：黄金比がつくる向日葵の種のシミュレーション

放送大学の自然科学の授業で，岸根順一郎さんが向日葵の種の配列のシミュレーションを見せていた。自然は黄金比を選んでいるというわけだ。バラメタを少し変えるといろいろな模様が出現する。

自分でも試してみたくて，バイブコーディングに走る。ChatGPT Auto で試したところ，Juliaに慣れていないせいか，なかなかエラーが消えない。しょうがないので，ChatGPT Thinking-5.4 でリセットしてからお願いする。プロンプトは以下のとおり。

Ｑ（koshix）：
Jupyter環境で，次のJulia プログラムをつくってください。向日葵の種（塗りつぶした色つき小円でよい）の分布が 1粒ずつ内側から充足されていくインラインアニメーション。これで意味が分かりますか？なるべく簡素で高速なものにしてください。

種の大きさや色相，パラメタの変更機能などを注文すると，「Julia で毎回 GIF や mp4 を作るより、Jupyter セル内に HTML/JavaScript の小さな UI を埋め込む方がずっと軽くて速いです。」ということで，修正版ができた。饅頭の薄皮だけJuliaで中身の餡子はすべてJavascriptというよくわからないけど，よくあるパターンらしい。

最後に，Gemini Pro に投げてコード全体を簡素化してもらったところ，少しスッキリした。黄金比の部分を変えると，様々なパターンが現われる。

この中からJavascriptのコードを含むhtmlを取り出して，独立で動くように修正し，角度係数αを，1.60〜1.83まで0.01刻みで変化させた結果を合成した画像も，ほとんどそのまま出力してくれた。プロンプトを0.1刻みと間違えて入力しても，正しく解釈してくれる。

図２：α = 1.60〜1.83までの向日葵パターンの変化

using UUIDs

function sunflower_simulator()

uid = "sf_" * replace(string(uuid4()), "-" => "")

html = """

</div>

α を黄金比 φ ≈ 1.618 にすると、回転角 2π/α ≈ 222.5° になります。<br>

ひまわり配列でよく使う黄金角 137.5° とは、向きが逆なだけで本質的に同じです。

</div>

</div>

(function() {

// DOM要素の取得を簡素化

const get = id => document.getElementById(`$(uid)_\${id}`);

const [alphaIn, nIn, stepIn, runBtn, canvas, info] = ["alpha", "N", "step", "run", "canvas", "info"].map(get);

const ctx = canvas.getContext("2d");

let animId = null;

function runOnce() {

if (animId) cancelAnimationFrame(animId);

const alpha = parseFloat(alphaIn.value);

const N = Math.max(1, parseInt(nIn.value));

const step = Math.max(1, parseInt(stepIn.value));

if (!isFinite(alpha) || alpha === 0) {

info.textContent = "α は 0 でない数を入れてください。";

return;

}

info.textContent = `α = \${alpha.toFixed(6)}, 回転角 = \${(360 / alpha).toFixed(3)}°, 粒数 = \${N}, 速度 = \${step}`;

// シード配列の生成 (Array.from でスッキリ記述)

const angle = 2 * Math.PI / alpha;

const seeds = Array.from({length: N}, (_, i) => {

const k = i + 1;

const r = Math.sqrt(k);

return {

x: r * Math.cos(k * angle),

y: r * Math.sin(k * angle),

color: `hsl(\${25 + 55 * (k / N)}, 90%, 59%)` // HSV(h, 78%, 96%) とほぼ同等のHSL色

};

});

const W = canvas.width, H = canvas.height;

const scale = 0.48 * Math.min(W, H) / (Math.sqrt(N) + 1);

const rad = Math.max(0.9, 140 / Math.sqrt(N + 20));

let k = 0;

// 描画とアニメーションループを統合

function tick() {

k = Math.min(k + step, N);

ctx.clearRect(0, 0, W, H);

ctx.save();

ctx.translate(W / 2, H / 2);

for (let i = 0; i < k; i++) {

ctx.beginPath();

ctx.arc(seeds[i].x * scale, seeds[i].y * scale, rad, 0, 2 * Math.PI);

ctx.fillStyle = seeds[i].color;

ctx.fill();

}

ctx.restore();

if (k < N) animId = requestAnimationFrame(tick);

}

tick();

}

runBtn.onclick = runOnce;

// Enterキーでの実行イベントをまとめる

[alphaIn, nIn, stepIn].forEach(el =>

el.addEventListener("keydown", e => e.key === "Enter" && runOnce())

);

})();

</script>

"""

display("text/html", html)

end

sunflower_simulator()

2026年3月30日月曜日

Claude Code

図：ターミナルにおける Claude Code の実行画面

菅野完が，斉藤元彦記者会見テキストをベースとしたオンプレミスAIを作成するという文脈で，Claude Code を絶賛していた。昔，途中まで試しかけてやめていたので再チャレンジしてみた。

まずは，brew install claude-code でインストールしたところ，既にnpmで入っていたものとぶつかってしまう。仕方がないので，アンインストールしてから，brew install --cask claude-code でOK。

ターミナルで，claudeとすると，図の実行画面になる。そこで，どうすればいいかを Claude Sonnet 4.6 に尋ねてみる。Claude-odeを使うには，有料のClaude Pro プラン（\$17/月 = \$200/年）か，API課金を選択する必要がある。API課金は青天井にならないか心配だったが，クレジットカードを登録したプリペイド方式なので大丈夫らしい。 \$5でも十分使えるらしい。

入力：\$3 / 100万トークン，出力：\$15 / 100万トークンのレートなので，\$10も課金すれば，数百から数千回のやり取りができるといわれた，ほんとかな。まあ，\$5≒800円で試してみよう。

サンプルとして，claudeのコンソールのプロンプト > で，create a util logging.py that outputs logs with timestamp を入力せよといわれたので，そのまま実行したら， ~/にlogging.py が生成された。この名前は本来のpythonにあるものと名前が重なっていたのでエラーとなった。名称をmy_logging.py として，別のターミナルウィンドウに，python の，source myenv/bin/activate 仮想環境で実行した。

やり方がわかったので，実際のコードをつくってみる。簡単な四則演算ということで，

> create a simple math quiz game in Python. Ask the user 5 random arithmetic questions

(addition, subtraction, multiplication), show the score at the end.

とすると，それらしいコードが生成された。

> query and comments shoid be in Japanese

で，日本語でのメッセージもOK。

❯ 日本語でもできますか？
⏺ はい、もちろんです！日本語で対応できます。何かお手伝いできることはありますか？

❯ a,b,c を入力したら，二次方程式の解を出力するコードをお願いします。
⏺ 何の言語がご希望ですか？

Python で書きます：
⏺ User answered Claude's questions:
⎿ · 使用する言語はどちらがよいですか？ → Python
⏺ プログラム：（回答略）
実行例：（回答略）
判別式 D = b² - 4ac の符号によって3パターンに分岐しています。

❯ このプロンプトから実行できますか？
⏺ はい、できます！例として a=1, b=-5, c=6 で実行してみます。
⏺ Read 1 file (ctrl+o to expand)
⏺ 正常に動作しています。3パターンすべて正しく出力されました。
別の値で試したい場合は「a=, b=, c=__ で試して」と言ってください。

❯ a=1, b=2, c=3
⏺ Read 1 file (ctrl+o to expand)
⏺ 結果： real = -b / (2 * a)
- 判別式 D = 2² - 4×1×3 = 4 - 12 = -8 < 0 → 虚数解
-{x1 = -1.0 + √2 i ≈ -1.0 + 1.4142i
- x2 = -1.0 - √2 i ≈ -1.0 - 1.4142i

［１］Claude Codeの概要

2026年3月28日土曜日

pdf2md

pandoc（３）・マークダウン（２）からの続き

図：ChatGPTによるMarkdownのイメージ

pdfをMarkdownに変換するOpenDataLoaderというツールがすごいというのをtwitterで見かけた。

pdfからテキストを抽出するツールはpdftotextなど沢山あるが，表などでテキストが構造化されていると，出力がぐちゃぐちゃして後処理が面倒なことになる。その点，Markdownは文書の構造を保持するので，事後の利用にもそのまま使えるというわけだ。無料，オープンソース，高速だから，論文・社内資料・契約書、全部MarkdownにしてそのままRAGに投入できる，という触れ込みだ。

そこまで要求しないので，ChatGPTに依頼してもとのソースコードを簡単にしてもらった。実行は，python環境で ./pdf2md.py ○○○.pdf とすればよく，○○○.md が出力される。試してみたところ，表などはうまく再現できていた。数式は未確認。あまり期待してはいけないというのが，ChatGPTのコメントである。ただのテキスト抽出よりはまし。

#!/usr/bin/env python3

# -*- coding: utf-8 -*-

# pdf2md.py

import sys

from pathlib import Path

import shutil

import tempfile

import opendataloader_pdf

def main():

if len(sys.argv) != 2:

print("使い方: python pdf2md.py input.pdf")

sys.exit(1)

pdf_path = Path(sys.argv[1]).expanduser().resolve()

if not pdf_path.exists():

print(f"ファイルが見つかりません: {pdf_path}")

sys.exit(1)

if pdf_path.suffix.lower() != ".pdf":

print(f"PDFファイルを指定してください: {pdf_path}")

sys.exit(1)

with tempfile.TemporaryDirectory() as tmpdir:

opendataloader_pdf.convert(

input_path=[str(pdf_path)],

output_dir=tmpdir,

format="markdown"

)

src_md = Path(tmpdir) / f"{pdf_path.stem}.md"

dst_md = pdf_path.with_suffix(".md")

if not src_md.exists():

print(f"Markdownファイルが生成されませんでした: {src_md}")

sys.exit(1)

shutil.move(str(src_md), str(dst_md))

print(f"作成完了: {dst_md}")

if __name__ == "__main__":

main()

2025年11月27日木曜日

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）

2025年11月24日月曜日

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）

2025年11月23日日曜日

ブログ保存ツール

しばらく前に一度やりはじめて挫折した件。再度，要求仕様を良く考えて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版）

2025年11月20日木曜日

元素周期表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. なにやら新しいグーグル検索機能が追加されたようなので試してみた。

2025年10月8日水曜日

関数電卓ウェブアプリ

バイブコーディングからの続き

気の迷いで関数電卓ウェブアプリを作らせてみようと思った。ChatGPT-5とGemini 2.5 Proを組み合わせてあれこれ試した結果，画面と機能の設計がかなり面倒だということがわかった。そこで，出発点としてiPhoneの計算機アプリを使うことにする。その画面と裏画面（2nd関数で表示されるもの）をキャプチャーしてこのようなものとChatGPT-5 Thinkingにお願いした。

Ｑ（koshix）：
Appleの計算機を参考に関数電卓のウェブアプリを作ってください。２つ画像があるのは1st関数リストと2nd関数リストを表現しています。
(1) 背景は薄い空や海のような自然で流れるような水色にしてください。
(2) 本体のボディはシルバーにして，ボタンとの違いをはっきりさせます。
(3) 表示部分は液晶的な背景にモダンな文字デザインにします。
(4) 有効数字は別列スイッチで6桁（単精度）と12桁（倍精度）の切り替え式に。
(5) 同様に角度の単位のラジアンと度のも別列スイッチで切り替え式に。
(6) %キーはやめてバックスペースキーBSにしてください。
　　BSは一つずつ順に前の計算/入力状態に戻していくキーになります。
(7) mc m+ m- mr はMC M+ M- MR と表示して区別できる薄緑色にしてください。
(8) Rand は rnd と表示します。
(9) EEキーは数字キーと同じ色に，Degキーは先ほどの%を盛ってきます。
(10) 2nd ボタンは色を変えて，押した状態では 1st と表示するようにして下さい。
(11) 計算式が薄いグレーの小文字で計算結果表示の上に出続けるようにしてください。
(12) 最上段の選択ボタンと関数電卓型のボタンは不要です。
ココまでの指示内容でで質問があればお願いします。よければ了解としてください。
その後，こちらで進めてくださいという指示を出します。

400行くらいのHTMLファイル（javascriptプログラム）がでてきて，動作確認の粘り強い往復やり取りをしながら一日かかって，570行くらいのプログラムができた。まだバグがたくさん残留している模様。とりあえず関数電卓ウェブアプリを公開しておく。

図：関数電卓ウェブアプリの画面

javascriptの文法やprograminngの仕組みを知らなくても，論理的で正確な日本語表現で，デザインや機能に対する要件を伝えることや，AIからのフィードバックを検証してみる過程を繰り返しながら完成に近づけていくということを学習できそうではある。

その前段階として，簡単なjavascriptを出力するような課題をあたえ，その結果を読解するような演習がありうる。そんなこんなで生成AIを自由に使える環境さえあれば，これまでのものとは一味違うプログラミング教育は可能だと思う。むしろバイブコーディングの方が如何に適確に相手に要望を伝えるかという訓練ができるのではないか。

［１］高校の授業でVibeコーディングをやってみた，千葉県立柏の葉高校前編

［２］Vibeコーディングはプログラミング教育をダメにする，千葉県立柏の葉高校後編

2025年8月22日金曜日

プログラミング教育2025

放送大学にチャンネルを合わせると，中川一史さんと文科省の折笠史典さんがでている「小学校プログラミング教育（導入編）」をやっていた。2019年のものかな。生成AI登場以前だ。それはそうとしても，なんだかなぁと感じたのでそのあたりをChatGPT-5の助けをかりて言語化してみた。「わかりやすく」とか言わないほうが面白い結果が得られる。

Ｑ（koshix）：
小学校のプログラミング教育において重要なことは「プログラミング的思考」を育成することだといわれています。ところが，その定義が手続き型プログラミング言語の仕組みの表層をなぞるようなものでしかありません。具体的な実践例も子供たち創造力を引きだすようなものにはなっていないと思います。
問題はコンピュータの利用において，これを単なる受け身のメディア再生機（YouTubeとゲーム）でなくて主体的に創造するための「ツール」として活用することにあるのではないかと思います。プログラミング教育はその一部を構成できると思いますが，一方でプログラミングなしで，通常のアプリケーションの活用だけでも同等のことが実現できるのではないでしょうか。この論点のついての分析と評価をお願いします。

Ａ（ChatGPT-5）：（回答略）

Ｑ（koshix）：
私の問題意識は，プログラミング的思考を育成するという目標設定それ自身がおかしいのではないかということです。目標はあくまでも創造的な「ツール」としてコンピュータを活用できるようになることです。そのなかにプログラミングという要素があることには全く依存がありません。アプリ中心であることにこだわっているわけでもありません。AI時代を迎えるにあたっての基本的な考え方の問題です。その辺があなたにうまく伝わっていないような気がします。

Ａ（ChatGPT-5）：（回答略）

Ｑ（koshix）：
いやここまでで結構です。どうもありがとうございました。放送大学の「小学校プログラミング教育（導入編）」という授業の内容を徹底的に批判してほしいのですが，たぶんあなたはそれにアクセスできないでしょうから無理ですね。

Ａ（ChatGPT-5）：（回答略）

Ｑ（koshix）：
（添付ファイル：koshix.blogspot.com の「小学校プログラミング教育」から）
小学校プログラミング教育とプログラミング的思考についてのこのブロガーの記事を年代順に把握理解してその主張を報告してください。

Ａ（ChatGPT-5）：（回答略）

Ｑ（koshix）：
「教育政策の批判軸」と「創造的活用へのシフト」という2本の柱で整理し、論説の形で分かりやすく説得的な日本語の文書にしてください。

Ａ（ChatGPT-5）：（回答略）

Ｑ（koshix）：
（添付ファイル：https://chatgpt.com/share/68a4532e-8ecc-8009-bbc3-d95802bfc5dd）
添付のテキストの内容も加味して，教育関係者向けの提言書スタイルのわかりやすく説得的で詳しい文章にまとめてください。

Ａ（ChatGPT-5）：（回答略）

Ｑ（koshix）：
分かりやすさを優先したためか，文章の深みに欠けています。箇条書きはなるべく減らした上で，深く思考を紡いだ長めの文によって論理を尽くして問題点をえぐり出してください。

Ａ（ChatGPT-5）：

提言書（ChatGPT-5 + koshix）

「プログラミング的思考」から「創造的コンピュータ活用力」へ——AI時代の小学校情報教育を設計し直す

序
小学校へのプログラミング教育導入は、「プログラミング的思考」という新奇だが曖昧な標語のもとに制度化された。だが、この標語は教育の最上位目的を示す理念としては脆弱で、しばしば“手段の目的化”を招き、現場に形式主義をもたらしている。むしろ目標は、子どもがコンピュータを自らの創造のための道具として使いこなし、情報を構想・生成・編集し、社会に働きかける力を培うことに置かれるべきである。この観点は、当初の政策決定過程のねじれや、現場で観察された実践の限界、そしてAIの到来によって一層鮮明になった。

１．概念輸入のねじれと制度文言の劣化
「コンピューテーショナル・シンキング（CT）」の輸入に端を発する議論は、当初、学習の設計・分解・抽象化といった広い知的実践を射程に入れていた。しかし政策化の局面で、用語は「プログラミング的思考」へと統一され、その意味内容は「意図した処理を実現するために、動きの組合せを記号で設計し、改善する」といった、手続き型プログラミングの表層に引き寄せられてしまった。ここで理念は二重に脱力する。第一に、目標を「思考法」に格下げすることで、子どもが道具を握って世界に関わるという行為のダイナミズムが霧散する。第二に、学ぶべき思考の実体がプログラミング言語の構文・制御構造の擬似体験に化け、学びの “中身” が希薄化するのである。このねじれは、政策文言の可搬性（どの学校でも言い回しだけは一致させられる）を優先した結果でもあったが、その代償として、子どもの創造的な営みを正面から扱う大胆さを失わせた。

２．形式主義が生む現場の負担と不均衡
「思考の育成」という抽象目標は一見、現場の裁量を広げるように見える。だが実際には、汎用教材で短時間に達成度を “見える化” する設計が横行し、キャラクターを一定の手順で動かすことが “学習の証拠” へとすり替わる。こうした授業で子どもが得るのは、コードの意味理解やシステム設計の経験ではなく、与えられたブロックの正しい並べ替えにすぎない。制度はその “達成” を評価しやすく、教員は達成形式を整えるための下準備に追われる。設備や研修のリソースが乏しい学校ほど、形式主義に依存する傾向は強まり、結果として教育機会の格差は拡大する。制度化の当初から、この副作用は鋭く指摘されていたし、現場感覚としても重くのしかかってきた。

３．教育目標の取り違え——“思考”という名の空洞化
決定的な問題は、「プログラミング的思考」という語が、手段の記述様式（記号列・制御構造）を “思考” に見立て、学習目標を手段側へ引き倒してしまったことである。子どもが学ぶべきは、コンピュータを介して世界に関わるための “作る・直す・伝える” というプロセスの統御であり、その中にプログラミングという選択肢が含まれるかどうかは、課題や道具選択の問題であって本質ではない。現行定義は、まさにこの順序を逆転させる。したがって、「手続き型の表層をなぞる定義では創造性が引き出されない」という批判は、的確であるだけでなく、政策の前提に遡る根本的な再審を促す。そしてこの批判は、単なる理念論にとどまらない。実際の授業は「迷路を解く」「キャラクターを動かす」といった課題に収束しやすく、子どもの関心や社会的文脈に接続されにくい。ここで子どもが体験するのは、世界に向けて “何かを成し遂げる” ための設計ではなく、正規解に収斂する “模倣の段取り” である。

４．反証としての実践——Scratchが示した“道具としての広がり”
他方、同じプログラミングの枠内でも、Scratchの拡張機能群とIoT連携は、授業が閉じた画面内の模倣から、音・身体・空間・外部データへと開かれうることを示した。ここでは、プログラミングは “コードを書く行為” というより、表現や探究のための “場づくり” として機能しうる。つまり、子どもの手に渡る道具箱が十分に多様で、課題が生活世界や学びの他領域に接続されているとき、プログラミングは創造のための媒介となる。この経験は、当初の懐疑を訂正し、目標が “思考のラベル” ではなく “創造の実践” であるべきことを、実証的に裏づけた。重要なのは、ここで価値を生んでいるのが「プログラミング的思考」なる抽象ではなく、道具の拡張性と課題設計の社会的・表現的接地だという点である。

５．AI時代が要請する転回——命令記述から振る舞い誘導へ
生成AIの普及は、コンピュータとの関わり方を「手続きの逐語的記述」から「振る舞いの誘導・評価・統合」へと劇的にシフトさせた。ここでは、プロンプトという高位の仕様を投げ、出力を批判的に吟味し、他のツールと組み合わせて目的の表現や解決に仕立て直すことが核心となる。つまり “作る” ことの意味が、コードの細部に宿るのではなく、道具の選択・役割分担・検証・再設計の循環に宿る構造へと変わったのである。したがって、教育の目標は「プログラミング的思考」の育成ではなく、「コンピュータを創造のために使いこなす統合的能力」の涵養に再定義されねばならない。そして、この能力はプログラミングを必須としない。ローコードやノーコードの環境、さらにはアプリの高度な機能だけで、十分に同等の学びが成立する局面は多い。鍵は、ツールの等価的な編成と批判的運用にあり、どの記法を採るかは従属的な決定である。

６．政策言語を書き換える——“道具としての創造”を最上位目的に
以上を踏まえると、政策文書は次のように言い換えられるべきだ。すなわち、「小学校段階では、子どもがコンピュータとAIを創造のための道具として主体的に活用し、情報を収集・生成・編集・表現する一連の営みを設計・実行・省察できるようにする」。この目標のもとでは、プログラミングは “取りうる手段の一つ” として位置づけられ、課題の性質と子どもの発達段階に応じて、アプリ、センサー、生成AI、データ可視化、メディア編集などと等価に選択される。評価も「正しく動くコード」から離れ、課題設定の妥当性、ツール選択の理由、失敗の記録と修正、成果の社会的・表現的意義といったプロセスの可視化へと移行する。こうして初めて、授業は “やったこと” のチェックから、“何を成し遂げたか” “どう変えたか” の探究へと質的転換を果たす。

７．実装への視座——授業設計・評価・教員支援
実装の要は三つある。第一に、課題を生活世界の問題や他教科の学びに接地させ、アウトプットを “誰かに届く表現” として設計すること。第二に、AIと人間の役割分担を明示化し、出力の根拠・限界・改変の痕跡を残すことで、子どもに “作ることの説明責任” を教えること。第三に、教員の専門性を「コード知識」ではなく「学習のオーケストレーション」に振り向け、ローコード／ノーコード教材やプロンプト例、失敗事例集を共有資産として整備することである。これらは、リソース差を埋め、形式主義に陥りやすい学校ほど “実質” へと近づけるための制度投資でもある。

結語
私たちが守るべき順序は単純である。第一に目的、次に手段。目的は、子どもがコンピュータを用いて世界に働きかける創造の主体になること。手段は、プログラミングであれ、アプリであれ、AIであれ、課題に応じて選び、組み合わせ、検証し、やり直すこと。いま必要なのは、「プログラミング的思考」という抽象の上塗りではなく、“道具としての創造” を最上位に置く政策言語への転換である。そこに立ち返るとき、授業は再び、生きた学びになる。子どもは、手続きの模倣者ではなく、技術と表現を編む設計者として教室に現れるだろう。

2025年8月7日木曜日

政党マップ（２）

政党マップ（１）からの続き

米国ではエプスタイン問題で大騒ぎらしい。トランプが煽ったエプスタイン陰謀論でMAGA信者は多いに湧き上がっていた。それが一転し，トランプ自身に火の粉が及びそうになって，エプスタイン陰謀論を否定隠ぺいし始めた。これにMAGAの一部が激怒しているとのことだ。これまでのトランプ政権最大の危機だといわれている。このMAGA騒動のおかげで日米関税交渉が妥結したという話がある。トランプはMAGAポピュリズムから逃走しているらしい。本当かどうか。

図：MAGAから逃走するトランプ（よしログから引用）

参院選も終ったことなので，上図の2次元マップにならって日本の政党を分類してみることにした。その結果を以下に示す。座標値はChatGPTが考えたものである。ただし，チームみらいのy座標は符号をこちらで変えた。彼らはポピュリズムじゃなくてエリート主義だろう。

Ｑ（koshix）：
参議院議員選挙の後の日本の政治状況を2次元グラフで表現したいと思います。
x軸正方向を右派，負方向を左派とします。
y軸正方向をエリート主義，負方向をポピュリズムとします。
各政党をその得票数に比例した面積に比例する円で表わします。政党のシンボルカラーで各政党の円を塗りつぶします。各政党の政策やニュース情報でそれぞれの政党の立ち位置を定めてください。

参考イメージとして米国の政治主張を例とした2次元グラフを添付します。（上図）

Ａ（ChatGPT o3）：
（注：フォント設定部分だけはこちらで修正している）
import math
import pandas as pd
import matplotlib.pyplot as plt
import matplotlib.patches as patches
import matplotlib.font_manager as fm
from matplotlib import rcParams

# フォントの設定
font_path = '/System/Library/Fonts/ヒラギノ丸ゴ ProN W4.ttc' # 適切な日本語フォントファイルを指定してください
font_prop = fm.FontProperties(fname=font_path)
rcParams['font.family'] = font_prop.get_name()

# --- データ（比例代表の得票率、Wikipedia「政党色」準拠の色） ---
data = [
# 政党, 略称, x(右派+ 左派-), y(エリート+ ポピュリズム-), 比例得票率(%), 色(Template:政党色)
("自由民主党", "自民", 0.55, 0.65, 21.64, "#3CA324"),
("公明党", "公明", 0.15, 0.55, 8.80, "#F55881"),
("立憲民主党", "立民", -0.35, 0.35, 12.50, "#184589"),
("国民民主党", "国民", 0.25, 0.10, 12.88, "#F8BC00"),
("日本維新の会","維新", 0.60, -0.25, 7.39, "#6FBA2C"),
("参政党", "参政", 0.90, -0.75, 12.55, "#D85D0F"),
("日本保守党", "保守", 0.85, -0.50, 5.04, "#0A82DC"),
("日本共産党", "共産", -0.70, -0.05, 4.84, "#DB001C"),
("れいわ新選組","れいわ",-0.55,-0.45, 6.56, "#E4027E"),
("社会民主党", "社民", -0.60, 0.15, 2.06, "#01A8EC"),
("チームみらい","みらい",0.05, 0.30, 2.56, "#66FFCC"),
("NHK党", "NHK", 0.50, -0.60, 1.15, "#F8EA0D"),
]

df = pd.DataFrame(data, columns=["政党","略称","x","y","比例得票率(%)","色"])

# 円の面積を得票率に比例させる（matplotlib の s は半径ではなく面積に相当）
SCALE = 1000 # 視認性のための調整係数。お好みで。
df["size"] = df["比例得票率(%)"] * SCALE

# 確認用にCSV出力
df.to_csv("party_positions_2025.csv", index=False, encoding="utf-8-sig")
print(df[["政党","略称","比例得票率(%)","x","y"]])

# 描画
plt.figure(figsize=(8,8), dpi=200)
plt.axhline(0, color="black", linewidth=1)
plt.axvline(0, color="black", linewidth=1)
plt.xlim(-1.05, 1.05)
plt.ylim(-1.05, 1.05)
plt.xlabel("← 左派右派 →")
plt.ylabel("ポピュリズム ↓ エリート主義 ↑")
plt.grid(True, linewidth=0.3, alpha=0.4)

for _, r in df.iterrows():
plt.scatter(r["x"], r["y"], s=r["size"], c=r["色"], alpha=0.35,
edgecolors="black", linewidths=0.6)
plt.text(r["x"], r["y"], r["略称"], ha="center", va="center",
fontsize=9, fontweight="bold")

plt.title("2025年参議院議員選挙後の日本政治 2軸配置（比例得票率で面積・試案）")
plt.tight_layout()
plt.savefig("japan_political_2d_2025.png", bbox_inches="tight")
plt.show()

図：比例区得票率に比例する面積で表わした日本の政党の２軸配置

登録: 投稿 (Atom)