fullseye

Qiita 記事の章構成組み替え計画(2026-09-02 起票 / 同日実施済み = commit 32e47171)

実施結果: ja/en とも 1196–1600 を 5 章へ置換。画像・GIF は各 153 件で欠落ゼロ、「追記N」/「Addendum」参照は 0 件、コード例の関数名 62 件は facade 実在を実行確認。実施後に著者から追加要望 ―― 「細かい使い方はヘルプで見てもらえばよい。ビジュアルにやれることを見せる方が好まれる」「サンプル処理画像・アニメ GIF を削らないこと」「博物館・科学館・展示会を思わせる規模まで画像/GIF を増やしてよい」「特に新機能は画面イメージ・3D 表示・アニメーションを多用してほしい。それがデバッグにも繋がる」。 → コード例は入口 1〜5 行に圧縮し詳細は docs/ops/<族>/guides/ と Studio の op ヘルプへ送った。展示の増設は docs/articles/exhibits/wing*.md に原稿を集約して本文へ合流させる方針。

なぜやるか

著者の指摘: 「追記が多すぎると記事的に綺麗でないので、機能的に章を分けるべき内容は、分けて書いたほうが良いかも」。

現状、本文の末尾に 追記1〜7 が時系列で 7 本ぶら下がっている。中身の大半は「いつやったか」ではなく「何ができるようになったか」なので、機能別の章に組み替えるほうが読み物として正しい。時系列の枠(「追記N(日付)」「この追記は …数日分です」)は外す。

対象ファイル

docs/articles/fullseye_overview_qiita_ja.md(124,863 字 / 1,621 行)
docs/articles/fullseye_overview_qiita_en.md(227,008 字 / 同じ章構成)

公開先は Qiita(ja=ef0422b143a1a3f09f92 / en=78e39b421211128f7b56)。 PATCH 手順は本文末尾の「実施手順」を参照。

現状の行番号(ja、2026-09-02 時点)

組み替え前にこの行番号を必ず取り直すこと(記事は編集されうる)。取り方:

grep -n '^## ' docs/articles/fullseye_overview_qiita_ja.md
awk 'NR>=1196 && NR<=1600 && /^###? /{print NR": "substr($0,1,72)}' \
    docs/articles/fullseye_overview_qiita_ja.md

記号	範囲	内容
A1	1196–1213	追記1 骨格まわり
A2	1214–1227	追記2 GPU 隠れバグ / 眠っていた 3D op / 手
A3	1228–1243	追記3 3D の処理領域と境界 / 歩き回り
A4	1244–1261	追記4 3D 大増強 / RLE の正体 / 1D は繋がっていなかった
A5	1262–1279	追記5 連鎖ファザー
A6h	1280–1285	追記6 見出し + Status + 導入
A6a	1286–1311	まず動画から
A6b	1312–1319	仕組み(画像でなく限界を返す)
A6c	1320–1338	「落とした理由を混ぜない」を 2 回
A6d	1339–1346	業界のアワードを op 発想の恒常的な入力に
A6e	1347–1366	新しい 2 分野(ライトフィールド / 光子計数)
A6f	1367–1387	「発見ゼロ」が頑健さに見えていた
A6g	1388–1395	型を分ける判断を 2 回
A6h2	1396–1403	進化語彙は増えたのか
A6i	1404–1421	来歴の規律を、文章から検査へ
A6j	1422–1434	この期間の数字(後述のとおり削除)
A7h	1435–1440	追記7 見出し + Status + 導入
A7a	1441–1455	何が入ったか(8 族の表)
A7b	1456–1488	この期間で一番の収穫(「発見ゼロ」は頑健さではなかった)
A7c	1489–1501	型を分ける判断を、実測で 6 回
A7d	1502–1515	「4 元数画像も使えたら面白いか」への正直な答え
A7e	1516–1530	既存版が壊れることを、測定に出す
A7f	1531–1561	進化が、新しい族を実際に使った
A7g	1562–1575	自分と Agent の誤りを 5 件
A7h2	1576–1587	副産物(公開直後の API のバグ)
A7i	1588–1600	この期間の数字

## まとめ は 1601 行から。1196–1600 を丸ごと置き換えるのが作業の実体。

組み替え後の構成(5 章)

各章に 新しい導入を 2〜4 行書く(旧 A6h / A7h の Status 行と「この追記は…数日分です」は捨てる)。### 見出しは機能名へ付け替える。

1. `## 計測モダリティを増やす ―― op 族をどう足してきたか`

導入: 「fullseye が一語も持っていなかった分野を、業界の一次情報から選んで埋めていった」。8 族 111 op という結果を先に置く。

順	元	新しい `###` 見出し(案)
1	A7a	何が入ったか ―― 8 つの族
2	A7e	既存版が壊れることを、測定に出す
3	A6e	ライトフィールドと光子計数
4	A7d	「4 元数画像も使えたら面白いか」への正直な答え
5	A4	3D 大増強と、「1D は足りないのではなく繋がっていなかった」
6	A3	3D に「処理領域」と「境界」を
7	A2	GPU の隠れバグと、眠っていた 3D op
8	A1	骨格まわりが一段深くなった

A1〜A4 は ## を ### に降格し、タイトルから「追記N(日付)」を落とす。

2. `## 部品を買う前に「見えるか」を確かめる ―― 仮想マシンビジョン環境`

導入: 「レンダラを持てないので、画像ではなく限界を返す層を作った」。

順	元	見出し
1	A6a	まず動画から ―― 「何 µm から見えるのか」を目で見る
2	A6b	仕組み ―― 「画像を作る」のではなく「限界を返す」
3	A6c	「落とした理由を混ぜない」を 2 回やった
4	A6d	業界のアワードを、op 発想の恒常的な入力にする

3. `## 品質保証の第三層 ―― op を鎖にして揺さぶる`

導入: 「単体テストと敵対的検証の次に、op を繋いだときだけ現れるバグを探す層を置いた。そしてその層自体が嘘をつくことを知った」。

順	元	見出し
1	A5	拡散と収束 ―― 連鎖ファザーの仕組み(`##`→`###` 降格)
2	A6f	「発見ゼロ」が頑健さに見えていた
3	A7b	「発見ゼロ」の正体 ―― 70 件が黙って飛ばされていた
4	A6g + A7c	型は意味の約束 ―― 型を分ける判断を実測で(2 つを 1 節に統合)

A6g と A7c は同じ主題なので繋げる。A6g の 3 例(polsweep / video / counts) のあとに A7c の 6 回目までを続ける形が自然。

4. `## 進化型のアルゴリズム開発環境 ―― 語彙とワークロード`

導入: 「語彙を 511 op に広げても、それを使う仕事が無ければ空回りする」。本文前半の層② の続きにあたる章であることを 1 行で示す。

順	元	見出し
1	A6h2	語彙は増えたのか ―― 増えていなかった、という実測
2	A7f	進化が、新しい族を実際に使った

5. `## 正直さを仕組みにする(続き) ―― 誤りの記録`

導入: 本文前半の「『正直さ』を仕組みにする」章の続きだと明示する。

順	元	見出し
1	A6i	来歴の規律を、文章から検査へ
2	A7g	自分と AI の誤りを 5 件、記録に残す
3	A7h2	副産物 ―― 公開した直後の API にバグがあった
4	A7i	数字で見るこの期間

何を書くか ―― 読者は感想文ではなく「使える技術」を取りに来ている

著者の指摘(2026-09-02、2 段階):

「そもそも我々にとって学びでも、読者の ROI とは一切関係ないなら書かなくてもいい気がする。」
「読者は感想文を読みたいわけではなく、使える技術を得るために読んでる。」

2 つ目が本質。1 つ目は「無関係なものを削れ」だが、2 つ目は 書き方そのものが間違っているという指摘である。現状の追記は書き手の視点で書かれている:

「この追記は…数日分です」「一番の収穫は」「私が踏みかけた罠」「> Status: Measured / Verified」

これは制作日誌の語彙であって、技術文書の語彙ではない。読者は 自分の仕事で何ができるようになるかを取りに来ている。

書き換えの規則

やめる(感想文)	かわりに書く(使える技術)
「一番の収穫は〜だった」	「〜という失敗様式がある。検出方法はこれ」
「〜を実装しました」	「`fs.xxx()` で〜ができる。入力・出力・単位はこれ」
「私が踏みかけた罠」	「この比較は同一 split で取ること。理由: 別抽出だと 20 倍盛れる」
「Status: Measured / Verified」バッジ	(削除。自己申告の品質バッジに読者価値は無い)
「著者から要望が来ました」	(削除。制作過程は読者の仕事に効かない)
「Agent が〜を報告した」	(削除。誰が作ったかは機能と無関係)
日付つきの「追記N」	機能名の章タイトル

各節が満たすべき形

読者が持ち帰れる単位で書く。節ごとに最低この 3 つ:

何ができるか ―― 1 文。API 名または章の機能名で。
どう使うか ―― 呼べるコード、または手順。引数の単位まで。
どこで壊れるか ―― 数字つき。閾値、破綻条件、既存手法との比較。

3 が無い節は「宣伝」であって技術ではない。逆に 3 だけあって 1・2 が無い節は「反省文」。現状の追記は 3 に偏り、1・2 が薄い。

具体的にこの記事へ当てると

残す(そのまま技術として強い): 位相シフト法が λ/4 で破綻する比較表 / 包絡線スペクトル 107.000000 Hz 対生スペクトル 4.3e-16 / 次数比分析の前後 / 四元数の結論(QFT は買わない・Riesz は負けた)/ 光学限界と検出限界を分ける設計 / 型を分ける判断基準(混ぜたら例外か、もっともらしく間違うか)。 ただしどれも「使い方」を足す ―― どの関数を呼ぶと出るのか。
規則だけ残して物語を捨てる: 「発見ゼロは未実行の偽装でありうる」→ 検出手順(族ごとのカバレッジ内訳・型到達可能性の不動点)として書く。「比較は同一 split」→ 規律として 3 行。誰がいつ間違えたかは書かない。
丸ごと削る: 制作過程、Agent の分担、Status バッジ、「数日分です」系の導入、「この期間の数字」の自己申告表(op 数の推移は読者の仕事に効かない。 何ができるかの一覧に置き換える)。

削った先の置き場

捨てるのではなく内部記録へ移す: コミットメッセージ / memory / docs/*.md。開発の経緯は我々には価値があるが、記事の紙面には要らない。

判断メモ(実施者への申し送り)

A6j(追記6 の「この期間の数字」)は削除する。 A7i が同じ行を新しい値で持つ累積版なので、2 つ並ぶと読者が混乱する。数値を隠すのではなく、後の版に一本化するという編集判断。迷ったら A6j の「前」列の値を A7i の脚注として残してもよい。
時系列の情報を完全に捨てない。 各章の導入に「いつの作業か」を 1 語だけ残す(例: 「2026-08 末から 09 頭にかけて」)。読者が開発の速度感を失わない程度に。
本文中の「追記5 の」「追記6 で作った」といった相互参照を潰すこと。組み替え後は章名で参照する。grep -n '追記[0-9]' docs/articles/*.md で洗う。
en 版は ja と同じ章構成に揃える。 見出しの英訳は既存の Addendum 見出しの語彙を流用する(例: ## Adding measurement modalities — how the operator families grew)。en の行番号は ja と違うので必ず取り直す。
まとめ / 次回に続くは動かさない。

実施手順

# 0. 行番号を取り直す(上記の grep / awk)
# 1. ja を組み替え(切り貼りは Python で。PowerShell で書き換えないこと)
#    → 見出しの付け替えと導入の書き足しは手で
# 2. 検算: 章数と本文長
grep -c '^## ' docs/articles/fullseye_overview_qiita_ja.md
grep -n '追記[0-9]' docs/articles/fullseye_overview_qiita_ja.md   # 0 件になること
# 3. en も同様に
# 4. コミット
# 5. Qiita へ PATCH(タイトル・タグ・公開状態は現行値を読んで戻す)
#    scratchpad の qiita_patch.py と同等のもの。marker は新しい章名にする

PATCH スクリプトの要点(前回使ったもの): 先に GET して title / tags / private を読み、そのまま送り返す。本文にローカルパスが混ざっていないか検査。PATCH 後に再 GET して反映を確認。トークンは ~/.config/qiita-cli/credentials.json の credentials[].accessToken。