--- title: kokurenの設計思想と開発史 tags: author: [kokuren](https://www.docswell.com/user/kokuren333) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/GE8DMZ6ZED.jpg?width=480 description: 自分の設計思想など 以下とClaude Codeで作成（Codexでも可） https://kokuren333.github.io/BookOrderWebUI published: September 29, 26 canonical: https://www.docswell.com/s/kokuren333/5MQR78-2026-09-29-051739 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/GE8DMZ6ZED.jpg) kokuren の設計思想と開発 史 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/LELM3D917R.jpg) Publication information / 出版情報: supplied by the author or publisher. # Page. 3 ![Page Image](https://bcdn.docswell.com/page/4JMYDPZ5JW.jpg) 目次 第 1 章 変わらない問い 1 1.1 kokuren という開発者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠1 1.2 一貫した問い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠2 1.3 四つの段階 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠3 第 2 章 AI が部品だった時代 6 2.1 medviser：根拠を外に置く . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠6 2.2 声と言葉の小さな道具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠7 2.3 この時期の役割分担 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠8 第 3 章 大量生成の時代 11 3.1 ObsidianVaultGenerater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠11 3.2 スライド・データ・サイト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠12 3.3 誰が正しさを確かめるのか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠14 第 4 章 エージェントと Skill 16 4.1 Skill という発明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠16 4.2 並列に育つ知識 Vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠18 4.3 生成物から生成過程へ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠19 第 5 章 広がる領域と設計原則 21 5.1 過剰設計という教訓 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠21 5.2 多領域へのひろがり . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠22 5.3 共通する設計原則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠24 第 6 章 本という最終形 26 6.1 Build Artifact としての生成物 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠26 6.2 BookOrder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠27 6.3 知的活動のループ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠28 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ⁠30 iii # Page. 4 ![Page Image](https://bcdn.docswell.com/page/PJR9416Z79.jpg) CHAPTER 01 変わらない問い この章では、本書が扱う開発者 kokuren と、その数年間の開発を貫く一つ の問いを紹介します。あわせて、生成 AI の能力向上に応じて開発のかたち が四つの段階を経て変わってきたことを概観します。つまり本章の役割は、 本書の見取り図と一貫した問いを示すことにあります。 1.1 kokuren という開発者 kokuren は、note で随筆を書き、GitHub で多くのソフトウェアを公開し ている個人開発者です。note のプロフィールには、医師であることと、創作 者であることが短く記されています[1]。医学の現場で「情報の根拠」に向 き合ってきた経験は、のちに見るように、開発の関心の中心にも表れてい ます。 本書は、この二つの公開された記録、つまり GitHub 上のリポジトリ と note の随筆を資料として、kokuren の開発と考え方の変化をたどります。 私生活や個人的な事情には立ち入らず、公開された成果物と、本人が文章で 語った設計の意図に焦点を当てます。 GitHub に公開されているリポジトリは、確認できる範囲で 52 件あり ます。最も古いものは 2023 年 12 月に作られた学習メモ用の静的サイトで、 2024 年に作られたものは 4 件、2025 年は 6 件でした。これに対して 2026 年 には 41 件が作られており、とくに 4 月に 20 件、9 月に 17 件と、作成が特 定の時期に集中しています[2]。 1 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/PEXQ2YM1JX.jpg) kokuren の設計思想と開発史 リポジトリが扱う領域も幅広いものです。医学情報の検索、音声合成、英 単語教材、スライド動画の作成、知識ベースの構築、学習アプリ、そして複 数の小さな AI アプリを手元で動かすための基盤まで並んでいます。2026 年 9 月には、資料から書籍を組み上げる BookOrderWebUI も作られました。 こうした件数の変化は、kokuren が急に熱心になったという話としてだ け読むと、大事な点を見落とします。同じ時期に、生成 AI は文章を返すだ けの道具から、自分で調べ、ファイルを読み、コードを実行して修正する存 在へと変わりつつありました。作れるものの量や種類は、使える AI の能力 とともに変わっていったのです。 そこで本書は、kokuren の開発史を「AI を使い始めたところから始まっ た物語」としてではなく、 「AI の能力が伸びるたびに、人と AI の分担が組 み替えられてきた過程」として読みます。何を人が決め、何を AI に任せる のか。その境界線の移り変わりが、開発の速度、扱う領域、作る対象、そし て考え方の変化を説明する手がかりになります。 定義 役割分担：一つの成果物を作る工程のうち、何を AI に任せ、何を 人間の判断として残すかという設計のことです。本書では、この境界線 の位置を段階ごとに比べていきます。 1.2 一貫した問い リポジトリの名前や使う技術は、時期ごとに大きく変わっています。それ でも、kokuren 自身は振り返りの随筆のなかで、2024 年から 2026 年まで、 形を変えながらほぼ同じ問題について作り続けてきたと述べています。そ の問題とは、 「情報として信頼できる AI 生成物をどう作るか」というもので す[3]。 この問いの背景には、医学に携わってきた経験があります。AI が引用を 付けて文章を書いたとしても、引用された論文が本当にその主張を支えて いるとは限りません。kokuren が求めたのは「絶対に間違えない AI」ではな く、間違っていたときに根拠までさかのぼって確かめられる生成物でした。 最初期の発想は、 「AI 自身を情報源にしない」というものでした。AI には 検索や要約、文章化を任せ、知識そのものは外部の検証可能な情報源から 持ってくるという分け方です。この考え方は、のちの段階でも形を変えて受 け継がれていきます。 ただし、問いが同じでも、答え方は使える AI の能力によって変わりまし た。AI が一つの工程しか任せられなかった頃は、引用を付けて答えさせる 2 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/3EK9M3GMED.jpg) 第 1 章 変わらない問い ことが工夫の中心でした。大量の文章を一度に書けるようになると、その品 質をどう保証するかが課題になりました。さらに AI が自ら調べて直せるよ うになると、調べ方そのものを渡し、生成の過程を記録して監査する方向へ と進みます。 kokuren は別の随筆で、生成 AI の本質を「知識増幅装置」というより「高 速な正のフィードバック装置」と表現しています。良い方向にも、思い込み を強める方向にも速く回るため、比較や反証、検証といった批判的な確認が 欠かせないという見方です[4]。AI の能力が上がるほど、この確認の仕組み をどこに置くかが重要になります。 同じ随筆で kokuren は、AI との対話で役立つ行為として、探索、分解、制 約、比較、反証、検証、成果物への変換の七つを挙げています。そして、こ れらは AI 時代に特有の新しい能力ではなく、従来からある知的活動そのも のだと位置づけています。AI は人の考える仕事を消すのではなく、その循 環を速めるものとして捉えられているのです。 こうして関心は、生成された文章そのものから、その文章がどの情報源と どの工程を経て作られたかという記録へと広がっていきました。最終章で 扱う「本」という形式は、この記録を一冊にまとめて固定する試みとして位 置づけられます（第 6 章）。 定義 来歴：生成物が、どの情報源と、どの工程を経て作られたかの記 録です。英語の provenance にあたり、本書では生成物の信頼性を説明す るための中心的な概念として用います。 1.3 四つの段階 kokuren の振り返りと公開されたリポジトリを重ね合わせると、開発の 歩みはおおむね四つの段階に分けて整理できます。どの段階でも問いは同 じですが、AI に任せられる範囲が広がるたびに、人が担う仕事の中身が変 わっていきました。 表 1.1 開発の四段階と役割分担 段階 時期 代表的な成 人の役割 AI の役割 部品として 2024 年ごろ 果物 medviser 処理の順序 決められた をコードで 一工程を担 書く う の AI 3 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/L73WYGN275.jpg) kokuren の設計思想と開発史 段階 大量生成 エージェント 時期 2025 年 2026 年前半 と Skill 領域の拡大 と本 2026 年後半 代表的な成 果物 ObsidianVault​ Generater evidencenote-​ generaterskill agent-home、 BookOrder​ WebUI 人の役割 AI の役割 テーマと量 記事を次々 を指示する 調べ方を手 に書く 自ら調べ、 順書として 実行し、直 渡す す 境界と検証 多領域で仕 の仕組みを 事を進める 設計する 第一の段階は 2024 年ごろで、AI が「部品」だった時代です。医学の質問 に引用付きで答える medviser では、検索、データ取得、文書の変換、AI の 呼び出しという処理の順序を、人が Python で一つずつ書いていました。AI は決められた一工程を担う存在でした（第 2 章）。 第二の段階は 2025 年で、大量生成の時代です。AI の文章力が上がり、テー マを一つ与えるだけで記事を次々に生成する ObsidianVaultGenerater が作 られました。知識らしい文章を作るコストはほとんど消えましたが、その大 量の記事の正しさを誰が確かめるのかという問題が、はっきりと見えてき ました（第 3 章） 。 第三の段階は 2026 年前半で、エージェントと Skill の時代です。AI が自分 で検索し、コードを実行し、不足を見つけて修正できるようになると、人は 処理の順序ではなく「どう調べるべきか」という仕事の進め方を手順書とし て渡すようになりました[3]。2026 年 4 月にリポジトリが集中して作られた のは、この転換と重なっています（第 4 章）。 第四の段階では、この仕組みが医学以外の領域や、複数のアプリを束ねる 基盤へと広がり（第 5 章）、最後に、来歴を備えた生成物の最終形として「本」 にたどり着きます（第 6 章）。次章では、まず第一の段階から、AI が一工程 を担っていた頃の開発を具体的に見ていきます。 この四段階を通して変わったのは、AI の使い方だけではありません。一 つの目的に一つのスクリプトを書く規模から、知識ベースや複数のアプリ を短期間に次々と作る規模へと、開発の速度も変わりました。扱う領域は医 学から語学、学習、研究一般へと広がり、作る対象も単発の道具から、生成 4 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/87DK51W6JG.jpg) 第 1 章 変わらない問い 物を検査し公開するための仕組みへと移っていきます。その途中には、AI が 設計を膨らませすぎたことによる失敗もありました。 まとめ • kokuren は、医師であり、GitHub と note で活動する個人開発者です。 • 開発は「AI の利用開始」ではなく、AI の能力向上に応じた役割分担の組 み替えとして読むことができます。 • 一貫した問いは「情報として信頼できる AI 生成物をどう作るか」です。 • 開発の歩みは、部品としての AI、大量生成、エージェントと Skill、領域 の拡大と本という形の四段階に整理できます。 演習 1. 「AI を使い始めたから開発が始まった」という見方と、 「AI の能力 向上に応じて分担が組み替えられた」という見方では、同じリポジ トリ一覧の読み方がどう変わるでしょうか。 2. あなたが普段 AI に任せている作業を一つ選び、その工程のうち人 が判断している部分と AI に任せている部分を書き分けてみましょ う。 3. AI が書いた文章について、根拠までさかのぼって確かめるには、ど のような記録が残っているとよいでしょうか。 5 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/VJPKGQXZE8.jpg) CHAPTER 02 AI が部品だった時代 前章では、kokuren の開発を四つの段階で見渡しました（第 1 章）。この 章では、その第一の段階を取り上げます。対象となるのは、2023〜2024 年、 人間が手順を書き AI は一工程だった時期です。処理の順序を決めるのは人 であり、AI はその流れのなかで決められた役目だけを担う部品でした。 2.1 medviser：根拠を外に置く 2024 年 1 月に公開された medviser は、知りたい医学情報を出典付きで得 るための小さなプログラムです。使い方はシンプルで、question.txt に質問 を書き、querymake.py、xmlget.py、xml2txt.py、medsum.py という四つの スクリプトを順に実行します。必要なライブラリは openai と requests だけ でした[5]。 四つのスクリプトは、それぞれ一つの工程を受け持っています。まず質問 から論文検索用の検索式を作り、次に論文データを取得し、それを読みやす いテキストに変換し、最後に回答文を書くという流れです。どの順番で何を するかは、すべて人がコードとして決めていました。 リポジトリには、 「癌を予防する食事や、リスクを高める食生活について 知りたい」という質問に対する回答例が添えられています。回答は、地中海 食や食物繊維などに関する説明の一文ごとに番号付きの参照を付け、末尾 に 20 件の文献名を並べる形になっていました。 6 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/2EVV65LMEQ.jpg) 第 2 章 AI が部品だった時代 回答の構成も決まった型に沿っています。最初に質問の要約を置き、次に 質問への回答を書き、最後に参考文献を並べるという順序です。どの形で出 力するかという枠組みも、AI が自分で考えたものではなく、人があらかじ め用意したものでした。 kokuren の振り返りによれば、medviser では GPT-4 に PubMed 用の検索 式を作らせ、NCBI の API から関連論文を 20 件取得し、その要旨をもとに引 用番号付きの回答を生成していました。根底にあったのは「AI 自身を情報 源にしない」という発想です。AI には検索式づくりや要約を任せ、知識そ のものは外部の検証可能な文献から持ってくるという分担でした。 一方で kokuren 自身は、この仕組みを「かなり雑」であり、EvidenceBased というより Evidence-Flavored だったと率直に評価しています[3]。引 用が付いていても、それぞれの主張を文献が本当に支えているかまでは確 かめていなかったためです。この自覚は、のちの段階で品質保証の問題とし て大きく育っていきます。 定義 Evidence-Flavored：根拠に基づく（Evidence-Based）ように見える 体裁を持ちながら、主張と根拠の対応が十分に検証されていない状態 を指す、kokuren の自己評価の言葉です。 2.2 声と言葉の小さな道具 同じ時期、kokuren は医学以外の領域でも小さな道具を作っていまし た。2024 年 2 月に公開された KantanKaiwa_Style-Bert-VITS2 は、Style-BertVITS2 という音声合成モデルと、簡単な音声会話をするためのスクリプト です。 定義 音声合成：文字で書かれた文章を、人の声のような音声に変換す る技術です。英語では Text-to-Speech（TTS）と呼ばれます。 会話の流れは次のようなものでした。ターミナルで「go」と打つと録音が 始まり、一定時間の無音で録音が終わります。その音声を Whisper で文字に 起こし、OpenAI の Chat モデルに送り、返ってきた文章を Style-Bert-VITS2 で音声に変換します。動画のデモでは gpt-3.5-turbo-0125 が使われていまし た。 リポジトリには、 「cotomo を目指して」改造した kaiwa02.py も含まれて います。ただし README には、Whisper では限界があるかもしれないとい う感想も記されています。部品を組み合わせる作り方では、全体の出来が 個々の部品の性能に左右されやすかったことがうかがえます。 7 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/57GLN6XXEL.jpg) kokuren の設計思想と開発史 最初の版には会話を覚える機能がありませんでしたが、2024 年 2 月 14 日 の追記で、直近の会話ログを一定件数だけ保持する簡単な記憶機能が加え られました[6]。聞き取り、応答、発声という工程をそれぞれ別の道具に割 り当て、それを人がつなぐという作りは、medviser とよく似ています。 2024 年 12 月には、英語学習者向けの単語リスト OANC_37k が公開されま した。Open American National Corpus をもとに 37,000 語を選び、難易度、日 本語訳、例文、例文の和訳を収録しています。語義や例文の一部は Gemini で 生成され、例文とその和訳の読み上げ音声は、Hugging Face 上の kokuren/ RinneElu という Style-Bert-VITS2 のモデルで作られました。 データは CSV 形式で、たとえば「know」という語には、難易度 A1、訳 語「知っている」、例文「I know the answer.」、和訳「私は答えを知ってい る。」が一行にまとめられています。一語ごとに同じ形式の行を並べること で、大量のデータを機械的に作り、検索しやすくしています。 ファイル数は 74,583 件に及び、ライセンスには ODC-PDDL が選ばれてい ます[7]。ここでは、文章を書く AI と声を作る AI を組み合わせ、人手では 難しい量の教材を作っています。ただし、どの語を選び、どの形式で並べる かという枠組みは、あくまで人が決めていました。 2.3 この時期の役割分担 ここまでの道具を並べると、この時期の人と AI の分担には共通した型が 見えてきます。 表 2.1 部品としての AI：三つの道具の分担 道具 medviser KantanKaiwa_​ Style-Bert-VITS2 OANC_37k 人が決めたこと 四つのスクリプ AI が担った工程 検索式づくりと 外部の資源 PubMed の医学 トの実行順と回 回答の執筆 文献 答の型 録音から発声ま 文字起こしへの での流れ 語の選定と CSV 応答文の作成 語義・例文の一 Whisper、StyleBert-VITS2 コーパスと音声 の形式 部の生成 合成モデル 第一に、処理の順序を決めていたのは人でした。medviser の四つのスク リプトも、会話スクリプトの録音から発声までの流れも、人が Python で書 8 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/4EQYQ485JP.jpg) 第 2 章 AI が部品だった時代 いた手順です。AI は、その手順のなかで検索式を作る、返答を書く、例文 を作るといった一つの工程だけを任されていました。 第二に、知識や声の土台は、AI の外に置かれていました。medviser では 医学文献、OANC_37k ではコーパスと音声合成モデルがその役割を果たし ています。AI が何でも答えるのではなく、外部の資源と AI を人が組み合わ せるという考え方が、この時期の特徴です。 第三に、一つひとつの開発は小さく、短期間で完結していました。 medviser のコミットは 2 件で、最初と最後が同じ日です。会話スクリプト も、主な作業は公開からおよそ 1 か月のうちに終わっています。目的ごとに 道具を作り、動いたらそこで手を離すという進め方でした。 この時期には、学習メモを載せる静的サイトの BiBo-Rock や、コーパス作 成のために日本語の音の連なりを数える cvchain といった、ごく小さなリ ポジトリも作られていました[8, 9]。いずれも、一つの目的のために一つの 道具を用意するという、手作りに近い規模の開発です。 kokuren の振り返りでは、翌 2025 年に AI がかなり賢くなったことで状況 が変わったとされています。AI の文章力が上がると、この分担は大きく揺ら ぎます。一工程だけを任せていた AI に、記事そのものを次々に書かせるこ とができるようになったからです。次章では、生成のコストがほとんど消え た 2025 年の開発と、そこで浮かび上がった品質の問題を見ていきます（第 3 章）。 まとめ • 2023 年末から 2024 年にかけては、人が処理の順序をコードで決め、AI は その一工程を担う部品でした。 • medviser は「AI 自身を情報源にしない」発想で、外部の医学文献に根拠 を置いていました。 • kokuren 自身は medviser を Evidence-Flavored だったと評価し、この自 覚がのちの品質保証への関心につながります。 • 音声会話スクリプトや OANC_37k でも、AI と外部の資源を人が組み合わ せる型が共通していました。 演習 1. medviser の四つのスクリプトのうち、AI が担っていたのはどの工 程で、人が決めていたのはどの部分だったでしょうか。 9 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/KJ4WNQ2V71.jpg) kokuren の設計思想と開発史 2. 「引用が付いていること」と「主張が根拠に支えられていること」 は、どのように違うでしょうか。 3. OANC_37k のように大量の教材を AI で作るとき、人が決めておく べき枠組みにはどのようなものがあるでしょうか。 10 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/LE1Y5PM47G.jpg) CHAPTER 03 大量生成の時代 前章（第 2 章）で見たように、2023 年から 2024 年にかけての kokuren の 開発では、人間が処理の順序を細かく書き、AI はその中の一工程を受け持 つ部品でした。2025 年になると、生成 AI の能力は大きく伸び、長い文章を まとまった形で、しかも速く書けるようになります。 本章では、この能力の伸びが開発の姿をどう変えたかを見ていきます。変 わったのは道具の数だけではありません。人間が指示する単位、AI が受け 持つ範囲、そして生成の対象そのものが、この時期に大きく広がりました。 同時に、それまで目立たなかった一つの問いが前面に出てきます。一言でま とめれば、本章が扱うのは「2025 年、生成コストの消失と品質問題の自覚」 という流れです。 3.1 ObsidianVaultGenerater 2025 年 9 月 20 日、kokuren は ObsidianVaultGenerater というアプリを公 開しました。Gemini を使う「Obsidian Vault Deep-Dive Agent」と名づけ られたこのアプリは、テーマを与えると、相互にリンクした知識ノートの束 （Obsidian Vault）を自動で生成し、ZIP ファイルとしてまとめて書き出しま す[10]。 ここで注目したいのは、AI に任される範囲の大きさです。前章の道具で は、AI は要約や回答といった一つの工程を担っていました。このアプリで は、記事を書き、その記事から「次に学ぶべき概念」を選び、さらにその概 11 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/GEWG523ZJ2.jpg) kokuren の設計思想と開発史 念について記事を書く、という展開の全体を AI が受け持ちます。人間が決 めるのは、出発点となるテーマと、どこまで広げるかという量の設定です。 生成のモードは二つあります。一つは、単一のテーマから出発して、相互 につながったノートを木のように広げていく「Single Topic」モードです。も う一つは、複数のテーマを起点に、中心となる入口ページから構造化された 知識の地図へ枝分かれしていくモードで、その入口ページは MOC と呼ばれ ます。 定義 MOC（Map of Concepts / Map of Content）：知識ノート群の入口とな る目次的なページ。個々のノートへのリンクを分野や論点ごとに並べ、 読者がどこから読み始めればよいかを示す。本書では、以後の章でも同 じ意味で用いる。 量の設定も細かく用意されています。一つの記事から派生させるノート の数、派生を繰り返す深さ、生成する記事の総数の上限（安全上限）を決め られます。README には、深さを大きくしすぎるとノートの数が指数的に 増えるという注意が書かれており、増えすぎを前提にした設計であること がうかがえます。 さらに、複数のワーカーによる並列生成の設定や、Web 検索を使わずモ デルの知識だけで書かせる設定もありました。生成されたノートは画面上 にリアルタイムで表示され、完成した Vault はそのまま Obsidian に読み込 めます。一つのテーマから数十、数百のノートが短時間で生まれる環境が、 個人の手元に整ったことになります。 3.2 スライド・データ・サイト 同じ時期、生成の対象はノートだけにとどまりませんでした。少し前の 2025 年 6 月 9 日には、medisidian というリポジトリに、医学知識をまとめ た静的サイトが公開されています。記録上は「Deploy Quartz site」という 一回のコミットだけで、4,276 件のファイルが一度に置かれました[11]。 このサイトの入口には、消化器、循環器、感染症、精神科、小児科など 18 の診療分野ごとに MOC ページが並び、その先に疾患ごとのページが続きま す。各ページは HTML と共有用画像の組で構成されています。一人の開発 者が、診療科を横断する規模の知識サイトを一度に公開できるようになっ たことを示す例です。 2025 年 11 月には、解説動画づくりの道具として BiimSlideMaker が作ら れました。想定された流れでは、まず Gemini などの長文に強いモデルに用 12 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/47ZLNDVLJ3.jpg) 第 3 章 大量生成の時代 意したプロンプトを渡し、テーマと目標枚数を伝えます。AI は Marp 形式の スライド原稿とナレーション台本を返し、人間はそれを確認して、GUI でス ライド画像・音声合成・動画出力を順に実行します[12]。 ここでの役割分担は、人間が「ディレクター」、AI が「執筆者」と言い表せ ます。人間は何を作るか、どれくらいの量にするか、どこを直すかを決め、 原稿そのものは AI が書きます。なお、このツールは 2026 年 3 月に別の音声 合成モデルへの対応が加えられ、周辺の技術の進歩に合わせて手直しされ 続けました。 生成は、学習用のデータづくりにも向けられました。ShareGPT_​from_​ Tweets は、X（旧 Twitter）の書き出しデータから純粋な文章だけのツイー トを取り出し、手元で動くローカル LLM に「このツイートが答えになる質 問」を考えさせて、質問と回答の組をデータセットにする仕組みです[13]。 一方で、生成に頼らない小さな道具も並行して作られています。2025 年 9 月 22 日の一日で作られた rsvp-segment-viewer は、日本語の文章をブラウ ザの中で区切り、一語ずつ高速に表示する読書用のビューアです[14]。思い ついた道具をその日のうちに形にできる速さも、この時期の特徴でした。 ここまでに挙げた成果物を、生成の対象、規模、人間の役割の三つの観点 で並べると、次のようになります。 表 3.1 大量生成期の成果物 成果物 ObsidianVault​ Generater 生成の対象 相互にリンクし 規模 一テーマから数 人間の役割 テーマと量を設 た知識ノート 十〜数百のノー 定する medisidian 医学知識の静的 ト 18 診療分野、 一度にまとめて BiimSlideMaker サイト スライド原稿と 4,276 ファイル 目標枚数を指定 公開する ディレクターと ナレーション台 した一本の動画 して確認し直す 本 質問と回答の組 書き出しから選 素材と生成の仕 のデータセット んだ文章だけの 組みを用意する 生成に頼らない ツイート 一日で作られた 思いついた道具 読書用ビューア 小さな道具 をすぐ形にする ShareGPT_​from_​ Tweets rsvp-segmentviewer 13 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/YJ6W815MJV.jpg) kokuren の設計思想と開発史 3.3 誰が正しさを確かめるのか こうして 2025 年には、知識らしい文章を大量に作るためのコストが、ほ とんど気にならない水準まで下がりました。人間はテーマと量を指示する だけで、ノートの束やサイト、スライドが手元に届きます。開発の速度も、 扱える領域の広さも、前の時期とは比べものにならなくなりました。 しかし、量が増えたことで、一つの問いが避けられなくなります。数百の ノートが生成されたとき、その一つひとつが正しいかを、誰がどのように確 かめるのでしょうか。ObsidianVaultGenerater には、Web 検索を使わずモ デルの知識だけで書かせる設定もありました[10]。その場合、記事の根拠を たどる手がかりは手元に残りません。 medisidian の例も、同じ問題を別の角度から示しています。4,276 件の ファイルは一回のコミットでまとめて公開されたため、どの資料をもとに、 どのような修正を経てページができたのかを、リポジトリから追うことは できません。成果物は大きくても、その生成過程は見えないままです。 反論・別解釈 もちろん、大量生成には利点もあります。ある分野の概念を網 羅的に並べ、全体の見取り図をすばやく得るには、量そのものが役に立ちま す。ObsidianVaultGenerater に記事数の上限が設けられていたことからも、 量を無制限に増やすことが目的ではなく、範囲を決めて広く見渡すための 道具として作られていたことが分かります。 それでも、kokuren が目指していたのは、前章の medviser に見られたよ うに、根拠を外に置いた、情報として信頼できる生成物を作ることでした。 本書では、品質の検証がないまま大量に生成された文章を AI Slop と呼びま す。大量生成の経験は、生成できることと、信頼できるものを作れることと が別の課題であることを、はっきりさせたといえます。 要点 生成のコストが下がるほど、生成物の正しさを確かめる仕組みの重 要性が増します。2025 年の大量生成は、kokuren の関心を「どれだけ作れ るか」から「作ったものをどう確かめるか」へと引き戻しました。 この問いに対する次の答えは、AI の能力がもう一段伸び、AI が自分で調 べ、読み、直せるようになったときに現れます。次章（第 4 章）では、AIエー ジェントと Skill によって、人間が渡すものがどう変わったかを見ていきま す。 14 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/GJ5M94YQJ4.jpg) 第 3 章 大量生成の時代 まとめ • 2025 年、生成 AI の能力向上によって、知識らしい文章を大量に作るコス トがほぼ消えた。 • ObsidianVaultGenerater では、記事の執筆から次の概念の展開までを AI が受け持ち、人間はテーマと量を指示する役に移った。 • 生成の対象は、ノート群、医学知識サイト、スライド動画、学習用データ セットへと広がった。 • 量の拡大は、生成物の正しさを誰がどう確かめるかという問いを前面に 押し出した。 演習 1. 前章の道具と ObsidianVaultGenerater とで、人間が決めることと AI が受け持つことはどう違うか、説明してください。 2. medisidian のように一回のコミットで公開された成果物につい て、生成過程を後から確かめにくいのはなぜか、考えてみてくださ い。 3. 大量生成が役に立つ場面と、品質の確認が欠かせない場面を、それ ぞれ一つずつ挙げてください。 15 # Page. 19 ![Page Image](https://bcdn.docswell.com/page/9E292VGW7R.jpg) CHAPTER 04 エージェントと Skill 前章（第 3 章）では、生成のコストがほぼ消えたことで、生成物の正しさを 誰がどう確かめるのかという問いが前面に出てきたことを見ました。2026 年に入ると、生成 AI の能力はもう一段伸び、AI は文章を書くだけでなく、 自分で検索し、ファイルを読み、コードを実行し、不足に気づいて調べ直せ るようになります。 本章では、この変化によって人間と AI の分担がどう組み替えられたかを 見ていきます。人間が渡すものは、処理の手順から「仕事の進め方」へと変 わり、関心の中心も、完成した記事から、記事ができあがるまでの過程へと 移っていきました。本章の主題を短く言えば、 「2026 年前半、手順ではなく 仕事の進め方を渡す」という転換です。 4.1 Skill という発明 2026 年 4 月 20 日、kokuren は evidence-note-generater-skill を公開しま した。臨床上の疑問を入力すると、根拠となる文献を探したうえで、日本語 と英語のエビデンスノートを作成する仕組みです。ここで AI は、もはや一 工程の部品ではなく、仕事全体を進める主体として位置づけられています。 定義 AI エージェント：自ら検索・ファイル操作・コード実行を繰り返 し仕事を進める AI。 Skill：仕事の進め方を Markdown で記述してエージェントに渡す手 順書。 16 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/D7Y4Y3V9EM.jpg) 第 4 章 エージェントと Skill リポジトリの指示書には、Codex 自身が推論・計画・統合・翻訳・ファイ ル出力を担い、補助スクリプトは検索・振り分け・整形・検証の支えにとど める、と明記されています[15]。前々章（第 2 章）の medviser では、処理の 順序を人間がプログラムとして書いていました。ここでは順序の細部を AI に任せ、人間はどう調べ、何を守るべきかを書いて渡します。 守るべきことも具体的に定められています。引用、ガイドライン名、 PMID、DOI、URL、アクセス日を捏造してはならず、質の高いガイドライ ンが確認できない場合はその限界を明記すること、インターネットが使え ないときは文献を作らずに止まること、などです。出力は日英二つのノート に限られ、見出しの構成も固定されています。 実例として公開されている小児ネフローゼ症候群の浮腫治療のノートで は、国際的なガイドラインや系統的レビューが番号付きの引用で整理され、 まだ分かっていない点も独立した見出しで示されています。自由に書かせ る部分と、必ず守らせる形式とを分けることで、AI の柔軟さと検証のしや すさを両立させようとする設計です。 この違いは、AI の能力が伸びたからこそ可能になったものです。処理を すべてコードで固定していた時期には、検索の語句や手順を変えるたびに 人間がプログラムを書き直す必要がありました。仕事の進め方を文章で渡 せば、エージェントは状況に応じて検索をやり直し、足りない根拠を探し、 形式に合わせて書き直せます。人間の仕事は、手順の実装から、良い仕事の 条件を言葉にすることへと移りました。 三つの時期を並べると、人間と AI の分担の移り変わりは次のように整理 できます。 表 4.1 三つの時期における人間と AI の分担 時期 部品（2024 年ご 人間が渡すもの 処理の順序を書 AI の役割 決められた一工 生成物 引用付きの回答 ろ） 大量生成（2025 いたプログラム テーマと量の設 程 記事の執筆と次 大量の知識ノー 年） エージェント 定 仕事の進め方を の概念の展開 調査・計画・執 ト 根拠つきのノー （2026 年前半） 書いた Skill 筆・確認 トと生成の記録 17 # Page. 21 ![Page Image](https://bcdn.docswell.com/page/VENYPVMDJ8.jpg) kokuren の設計思想と開発史 4.2 並列に育つ知識 Vault 同じ 4 月の末、kokuren は医学以外の分野にもこの考え方を広げます。 general-research-vault-skills は、あらゆる分野の問いについて信頼できる 情報源を調べ、日本語の Obsidian Vault 向けのリサーチノートとして蓄積す るための Skill 群です。 この指示書では、重要な主張に番号付きの引用を付け、参考文献には DOI か公式の URL を含めることが求められています[16]。一方で、何を信頼でき る情報源とみなすかは分野ごとに柔軟に変えるとされ、査読論文だけでな く、公式ドキュメント、一次資料、法令、標準、制作者本人の解説なども、用 途に応じて評価の対象になります。まだ存在しないノートを勝手にリンク にせず、「今後の作成候補」として書き出すという細かな約束もあります。 量の面では、記事のタイトルと知りたい内容を CSV に並べ、複数のワー カーで並列に生成するスクリプトが用意されました。こうして、2026 年 4 月だけで、音楽理論と信号処理、計算論的精神医学、RAG 評価、医療 AI 評 価、Python、イラスト創作と漫画制作、データサイエンスと Kaggle、精神 科 LLM の安全性評価、小説執筆の技術という 9 本の Vault が作られていま す[17–26]。 同じ時期には、研修医が当直や病棟で読み返せる臨床クエスチョン集や、 人間科学の 4 分野を扱う知識ベースも個別に作られました[27–31]。研修医 向けの知識ベースでは、日本のガイドラインと国際的な資料の両方を確認 することや、統一された見出し構成が指示書に定められています。救急領域 のクエスチョン集は、Quartz をもとにした静的サイトとして公開されまし た[32]。 4 月 30 日には、日常の疑問を信頼できる情報源に基づいて解説し、一つ の Vault に日付順に蓄積する daily-question-explanation-vault-skills も作ら れました。同じ内容を別の日に聞かれても既存の記事は書き換えず新しい 記事を作り、後日の関連づけは入口ページで行うという、記録を上書きしな い方針が定められています[33]。 要点 2026 年前半には、前章の大量生成と、medviser 以来の根拠に基づく 生成とが一つに合流しました。人間は問いの一覧と仕事の進め方を用意 し、エージェントが調査から執筆、確認までを並列に進める、という分担 です。 18 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/Y79P36N8E3.jpg) 第 4 章 エージェントと Skill 4.3 生成物から生成過程へ 2026 年 5 月から公開の記録が残る Evidence-Based-Everything は、この流 れをさらに進めたものです。医学で根拠に基づく医療を重んじる考え方を、 学問や実務、創作、技術などあらゆる分野へ広げ、情報源に基づいた記事を 継続的に編纂することを目指しました。約 30 の Skill が、問いの分類、情報 源の探索と評価、主張の抽出、矛盾の確認、執筆、引用監査、品質監査とい う順序で組み合わされています[34]。 特徴的なのは、完成した記事だけでなく、その記事を支える情報源のメ モ、主張と根拠の対応表、監査や公開の記録を、それぞれ別の場所に保存す る点です。公開の可否は「Publish Gate」と呼ばれる条件で判定されます。主 要な主張が情報源に結びついていること、限界や論争点が書かれているこ と、更新履歴があることなど、十数の条件を満たさない記事は公開されませ ん。公開用のリポジトリには、2026 年 5 月の 9 日間に、医学・心理学・教 育などの記事が私的な Vault から自動で同期され続けました[35]。 ここで関心の置き場所ははっきりと変わっています。前章の問いに対し、 kokuren は、良い記事を一本ずつ確かめるのではなく、記事ができるまでの 過程を後から監査できる形で残すという答えを示しました。情報源から証 拠、主張、記事へと至る流れそのものが、成果物の一部になったのです。 この仕組みは、Discord のボットからジョブを登録し、隔離された作業領 域でエージェントが記事を作り、成功したものだけを公開するところま で自動化されていきました。後継の Evidence Based Slopedia では、複数の ワーカーによる並列実行や、静的サイトの構築と自動公開まで組み込まれ ています。その公開先のサイトには、学術的・技術的な話題から趣味や身近 な話題まで幅広い記事が、同じ公開条件のもとで並びました[36]。 反論・別解釈 自動化が進むほど、仕組みそのものの保守は難しくなります。 Evidence Based Slopedia の README 冒頭には、このリポジトリは完全な AI Slop であり修繕できない技術的負債を抱えている、という運用上の警告が 置かれ、ゼロから作り直す計画が別の文書にまとめられています[37]。 エージェントと Skill は、確かめられる生成物への大きな一歩でした。同 時に、作れる範囲が広がったことは、新しい難しさも生みます。次章（第 5 章）では、速度が生んだ多領域への展開と、そこから引き出された設計の原 則を見ていきます。 19 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/G78DMZKZ7D.jpg) kokuren の設計思想と開発史 まとめ • 2026 年、AI エージェントが自ら調べ、読み、直せるようになり、人間が 渡すものは処理手順から仕事の進め方を書いた Skill へ変わった。 • evidence-note-generater-skill は、AI に仕事の主体を任せつつ、捏造の禁 止や出力形式の固定で検証しやすさを保った。 • general-research-vault-skills により、大量生成と根拠に基づく生成が合 流し、分野ごとの Vault が並列に育った。 • Evidence-Based-Everything では、記事だけでなく情報源・主張・監査の 記録を分けて残し、生成過程そのものを成果物とした。 演習 1. medviser の処理手順と、evidence-note-generater-skill の Skill とで は、人間が書いて渡すものがどう違うか説明してください。 2. 何を信頼できる情報源とみなすかを分野ごとに変える必要がある のはなぜか、二つの分野を例に考えてみてください。 3. 完成した記事だけでなく生成過程を保存することには、どのよう な利点と負担があるか整理してください。 20 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/L7LM3DZ1JR.jpg) CHAPTER 05 広がる領域と設計原則 5.1 過剰設計という教訓 前章で見たように、Skill によって仕事の進め方を AI エージェントに渡せ るようになると、開発の速度は大きく変わりました（第 4 章）。2026 年の夏 から秋にかけて、kokuren の GitHub には規模の大きなリポジトリが数日単 位で現れます。本章では、2026 年夏〜秋、速度が生んだ多領域展開と共通 原則を順に見ていきます。速度の上昇は、まず設計の野心を大きくする方向 に働きました。 open_learn_core は、構造化された教育ソースから、Web・PDF・動画に またがる学習教材を再現可能な形で組み立てようとするフレームワークで す。共有スキーマや検証、品質ゲートを持つ Core と、科目固有の知識や教材 を持つ Domain を分け、専用の置き場には 33 個の専門 Skill が並びました。 2026 年 8 月 28 日からの 2 日間で 33 件のコミットが重ねられています[38]。 線形代数の領域では、30 個の中核概念のうち「基礎（basis）」だけが 21 ブロックの学習体験を備えた最初の完成概念とされ、残りの 29 概念は同じ 品質ゲートを通るまで骨組みの状態に留め置かれました。広い枠組みを先 に作り、品質を満たした部分から公開していく段階的な設計です。 PDF は Pandoc と LuaLaTeX で、動画は Marp CLI や ffmpeg、音声合成の VOICEVOX Engine で作れるようにするなど、出力形式も一つの基盤の中に 21 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/4EMYDPV5EW.jpg) kokuren の設計思想と開発史 まとめられました。教材づくりの全工程を専門の Skill に分け、エージェン トに分業させる構想だったといえます。 続く researchos_public では、情報源・根拠・主張・概念を結びつける公 開知識基盤が、3 日間で 37 件のコミットとともに整えられました。寄稿者 向けの規則には「AI 生成の文章は根拠（Evidence）として扱わない」と明 記されています。Skill には理解・評価・設計・分析・統合という分類と、骨 組みから監査済みまでの成熟度が定められました。一方で、実装済みとされ たのは論文の批判的吟味を扱う一つの流れに限られていました[39]。 kokuren 自身は後に、統一データモデルへの抽象化や、Web・PDF・動画 までを同じソースから組み立てようとした守備範囲の広さを、失敗として 振り返っています（第 6 章）。作ること自体の負担が軽くなると、設計の範 囲はいくらでも広げられてしまうのです。 要点 AI は実装する力だけでなく、設計を膨らませる力まで増幅します。 この自覚が、以後の開発を小さく具体的な道具へ向かわせました。 5.2 多領域へのひろがり 大きな基盤づくりと並行して、9 月には領域の異なる小さなアプリケー ションが次々に公開されました。研究の継続支援、適応型学習、自己管理、 SNS 投稿の分析などです。多くは 1 日から数日でまとまった形になってお り、アイデアから公開までの距離がそれまでより大きく縮んだことがうか がえます。 ResearchCompanionOS は、会話から決定・失敗・根拠などの知見を取り 出し、構造化された記録として残すデスクトップアプリです。SQLite を正本 とし、Obsidian は人間が読むための投影と位置づけられています。挨拶や 進捗、未検証の推測は保存しないという線引きもあります。 Challenge Tree は、回答を評価して次の学習ノードを生成する適応型学 習アプリです。AI の処理は利用者の PC 上で動くコネクタを通じて行わ れ、許可される操作は五つに限られています。Web 検索の完了が確認でき なかった結果は保存しない仕組みも組み込まれ、12 件のコミットはすべて 9 月 13 日の 1 日で行われました[40, 41]。 自由意志大政奉還は反対に、アプリの内部で AI の推論を一切行いま せん。ChatGPT などの外部 AI が作った方針データを読み取り専用で扱い、 日々の状態を監査する役割だけを担います[42]。 22 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/PER9412ZJ9.jpg) 第 5 章 広がる領域と設計原則 占術を横断する森羅万象鑑も、アプリ自体には AI を組み込まず、依頼 データを ZIP で書き出して利用者が外部の AI に渡し、その結果を読み込ん で検証・表示するという同じ型をとっています[43]。 日本語の SNS 投稿の攻撃性を推定する Chrome 拡張は、投稿本文を外部 へ送らずブラウザの中で推論し、結果は倫理的・法的な判断ではないと明記 しています。同じ 9 月に作られた、日本語の文章を四つの状態に分類する別 の Chrome 拡張も、判定をブラウザの中で完結させ、出力は学習したラベル に基づく推定値であって真値ではないと限界を示しています[44]。 また、SNS 上の投稿を集計する静的ダッシュボードの Jigoku-no-Mon は、 投稿本文を掲載せず、集計方法や判断基準は公開する一方で収集の実装は 公開しないという線引きをとり、9 月 17 日の 1 日で 35 件のコミットが重ね られました[45]。 対象は AI を使うアプリに限りません。音楽制作では、C++で書かれた Windows 向けのシンセサイザープラグインが、9 月 6 日の 1 日で公開用の説 明の整備から 0.4.0 のリリースまで進みました。AI と直接関係しない技術領 域でも、個人が短期間でプロジェクトを立ち上げられるようになっていた ことがわかります。 同じ 9 月の note には、コーディング用のエージェントを使わず、ChatGPT に標準で備わる Python 実行環境だけで楽譜のアレンジから動画化までを 進めた体験も記されています。ジャンルや奏法、音源を逐一調べさせる細か な指示が成功の鍵だったとされます[46]。 これらのアプリは、9 月 16 日の 1 日で 19 件のコミットが行われた agenthome というランチャーに集められていきます。既存アプリの画面と中身の 処理はそのまま残し、AI との接続や保存の部分だけをアプリごとの境界に 隔離する方針がとられました[47–50]。 表 5.1 広がった領域と AI の位置 プロジェクト Research​ CompanionOS 領域 研究の継続支援 Challenge Tree 適応型学習 AI の置き場所 会話から知見を 境界の作り方 SQLite を正本、 取り出す Obsidian を投影 利用者の PC 上の とする 許可する操作を コネクタ 五つに限る 23 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/P7XQ2YD1EX.jpg) kokuren の設計思想と開発史 プロジェクト 自由意志大政奉 領域 自己管理 還 AI の置き場所 アプリの外（外 境界の作り方 方針データを読 部 AI） み取り専用で扱 SNS 攻撃性推定 SNS 投稿の分析 ブラウザの中 う 投稿本文を外部 拡張 agent-home アプリの束ね アプリごとの接 へ送らない AI との接続と保 続部分 存を境界に隔離 する アプリだけではありません。同じ時期には、医師国家試験 9 年分・3,556 問 に対する意思決定モデルの評価を、コードや統計、図表まで含めて公開した ベンチマークもあります。原稿には、生成 AI をコード開発や統計設計、執筆 などに用いたことと、内容の責任は著者が負うことが記されています[51]。 領域はばらばらに見えますが、どのプロジェクトも「AI をどこに置き、ど こで止めるか」を設計の出発点にしています。 5.3 共通する設計原則 こうした設計を読み解く手がかりが、2026 年 8 月に kokuren が note に書 いた楽器設計の随筆です。そこでは、ピアノは音高と鍵盤をほぼ一対一に対 応させる代わりに内部の機構を大きく複雑にし、ギターは少ない弦を人間 が組み替えて使う代わりに運指の習得を求める、と比較されています。 どの楽器も完成度が低いのではなく、異なる目的を優先した結果として、 異なる場所に不便さを抱えている。随筆はそう整理したうえで、すべてを自 動化すれば演奏は「再生ボタン」に近づくと述べ、消すべき不便さと残すべ き不便さを選ぶことが設計の本質だと結論づけます[52]。 具体案として示されたのが「66 点マイコン押弦方式」です。左手のコード 運指だけをマイコン制御で自動化し、右手のストロークや強弱、リズムは人 間に残します。何を機械に渡し、何を人間に残すかという問いは、そのまま AI との役割分担の問いとして読むことができます。別の記事では、この発 想をさらに進め、機械が押弦することを前提に弦楽器そのものを設計し直 す Mechanical Fret Instrument という構想も示されています[53]。 この観点から前節のプロジェクトを見直すと、三つの原則が浮かび上が ります。AI に任せる範囲を操作の種類や実行場所で区切ること。AI の出力 24 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/37K9M3XM7D.jpg) 第 5 章 広がる領域と設計原則 を事実ではなく監査の対象となる生成物として扱うこと。機械が扱う正本 と人間が読む表現を分けておくことです。 同じ原則は、知識を扱う Skill にも見られます。Sakurai-Skills は、ゲーム デザインに関する動画シリーズをもとにした中間ノートから原則を取り 出し、資料に記録された内容、そこからの抽象化、エージェント向けの解釈 を区別して保持しています[54]。9 月 26 日に整えられた Human-Skills-Skills も、生成する知識を人間が読み、検索し、再利用するための形式と定め、新 しく生成するときは作者名などのメタデータを捏造しないよう求めていま す[55]。 9 月下旬に 5 日間で 37 件のコミットが行われた CosmoOrder は、この考 え方を学習教材に当てはめた例です。「Build once. Learn many times.」を 掲げ、AI の計算資源を毎回同じ説明の生成に使うのではなく、一度作った 教材を残して何度も学べるようにします。参照先、根拠、制作の来歴を分け て扱い、文単位の検証はまだ実装していないと明記しています[56]。 要点 共通する原則は三つです。範囲を区切る、出力を監査する、正本と 投影を分ける。どれも「何を AI に渡し、何を人間に残すか」を決めるた めの工夫です。 AI の能力が低かった時期には、人間が処理の手順を書き、AI はその一工 程でした。能力が高まった今、人間の仕事は工程を書くことから、境界と検 証の仕組みを設計することへ移っています。この原則を一冊の成果物の形 にまとめる試みが、次章で扱う本という形式です（第 6 章）。 まとめ • 開発速度の上昇は、多領域への展開と過剰設計の両方を生みました。 • 9 月に公開されたアプリ群は、AI をどこに置きどこで止めるかを設計の 出発点にしていました。 • 共通する原則は、範囲の限定、出力の監査、正本と投影の分離です。 演習 1. open_learn_core が 29 の概念を骨組みの状態に留めた理由を、品 質ゲートという言葉を使って説明してください。 2. 自由意志大政奉還と Challenge Tree では、AI の置き場所がどう違 うかを比べてください。 3. 身近な道具を一つ選び、 「消すべき不便さ」と「残すべき不便さ」を それぞれ挙げてみてください。 25 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/LJ3WYG52J5.jpg) CHAPTER 06 本という最終形 6.1 Build Artifact としての生成物 ここまでの章では、生成 AI の能力が高まるたびに、kokuren の開発にお ける人と AI の分担が組み替えられてきたことを見てきました（第 5 章）。本 章では、その流れが行き着いた先として、AI 生成物の扱い方そのものの転 換と、「本」という出力の形を取り上げます。テーマは、監査可能な Build Artifact としての本と、AI 時代の知的活動です。 2026 年 9 月の随筆で、kokuren はそれまでの 3 年間を振り返っています。 2024 年 1 月の medviser は、GPT-4 に PubMed の検索式を作らせ、取得した 論文から引用番号付きの回答を生成するプログラムでした。「AI 自身を情 報源にしない」という発想でしたが、本人は根拠に基づくというより「根拠 風味」だったと評しています[3]。 2025 年 9 月の ObsidianVaultGenerater では、一つのテーマから記事を再 帰的に大量生成できるようになりました。しかし、100 記事を生成できるこ とは 100 記事分の価値を作ったことを意味しない、という問題が残りまし た[3]。2026 年には、AI エージェントに調べ方そのものを Skill として渡す方 式へ移ります。 その先でたどり着いたのが、AI 生成物を完成品ではなく Build Artifact と して扱う考え方です。問いから検索、情報源、根拠、主張、草稿、査読、監 査を経て公開される成果物までを、一続きのビルド工程としてとらえます。 26 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/8JDK51D6EG.jpg) 第 6 章 本という最終形 検索した文書を回答に添えるだけでなく、生成物そのものに来歴を持たせ ることが目指されました[3]。 定義 Build Artifact：完成品として信じてもらうのではなく、どの情報 源と工程を経て作られたかという来歴をたどり直せる形で残された生 成物。 重要なのは「この AI は賢いから信用してください」と言うことではなく、 「この主張はこの情報源までたどれる」 「この監査を通過した」と説明できる ことです。信頼の置き場所が、AI の能力からプロセスの記録へ移ったとい えます。 表 6.1 四つの段階と信頼の置き場所 段階 部品（2024 年） AI の役割 検索式と回答を 人間の役割 処理の順序を書 信頼の置き場所 外部の文献（た 作る く だし対応は未検 大量生成（2025 記事を再帰的に テーマと量を決 証） 置き場所が定ま 年） エージェントと 書く 自ら調べて書き める 調べ方を手順書 らない Skill に書かれた Skill（2026 年） Build Artifact 直す ビルド工程の各 にする 工程と監査を設 規則 来歴と監査の記 （2026 年 9 月） 段を担う 計する 録 6.2 BookOrder kokuren は、来歴つきの成果物の最終的な出力先として書籍を選びまし た。書籍は一つのテーマについて必要な情報を選び、章立てし、順序をつけ、 引用をまとめ、ある時点の知識を一つのまとまりとして固定できます。情報 の生成が無限になったからこそ、有限に編集された情報の価値がむしろ上 がる、という見方です[3]。 もちろん、本にすれば自動的に信頼できるわけではありません。数百ペー ジについて、なぜこの情報を入れたのか、何を根拠にしているのか、何を捨 てたのか、矛盾していないか、どの監査を通過したのかを管理する必要があ ります。kokuren はこの管理の難しさこそを課題として挙げています。 BookOrder の利用者は、書籍の計画や資料、URL、調査や図版の方針を入 力してジョブの ZIP を受け取り、ファイルやコマンドを扱える AI エージェ 27 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/VEPKGQ6Z78.jpg) kokuren の設計思想と開発史 ントに一つの指示を与えます。「bookorder goal が STATUS: COMPLETE を 表示するまで出版ジョブを最後まで実行する」という指示です。ジョブを作 る画面は完全に静的な Web アプリで、AI の API やバックエンド、アカウン トの仕組みを持たず、資料はブラウザの中で ZIP にまとめられます。 エージェントに向けた規則には、完了を決めるのはオーケストレータだ けであること、セッションの都合で仕事を縮めてはならないことが書かれ ています。オーケストレータは、資料の取り込みから追加調査、構成、執筆、 監査、組版、検証、パッケージ化までの全工程を管理し、17 の出版ゲート を満たしたときにだけ完成を宣言します。AI は調査・執筆・修正を自ら進 めますが、完了の判定と品質の検証は仕組みの側に置かれています。 出版の流れは、Markdown と YAML による正規のソースと、PDF などの 出力表現を分けて管理します。章立て・引用・図版・数式は正規のソースで 一元管理され、デザインの仕様や組版の処理は別の層に置かれます。CSS、 Typst、DOCX といった出力は共通のデザイントークンを共有し、同じ原稿 から複数の形式を作り分けます。前章で見た正本と投影の分離が、ここでも 受け継がれています。 同時に README は、生成されたジョブだけでは調査の質や執筆・編集の 質は保証されず、それらはエージェントとそのツールに依存すると限界を 明記しています。こうした仕組みの実装は、2026 年 9 月 28 日の 1 日で 10 件 のコミットとして進められました[57]。 要点 BookOrder では、AI エージェントが調査から組版までを進め、完了 の判定と監査は仕組みが受け持ちます。人間は計画と資料を渡し、検証の 置き場所を設計する側に回ります。 6.3 知的活動のループ 反論・別解釈 生成 AI を使うと自分で考えなくなり、思考力が衰えるのでは ないか。この懸念は広く共有されており、kokuren も随筆の題としてこの問 いを掲げています。 2026 年 8 月のその随筆で、kokuren は ChatGPT との対話における実践と して、探索・分解・制約・比較・反証・検証・成果物への変換の七つを挙げ ています。これらは AI 時代に新しく生まれたものではなく、従来からある 知的活動だと述べます。生成 AI の使い方を学ぶこと自体も、まずは AI との 対話の中で試せるという立場です。 28 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/27VV653M7Q.jpg) 第 6 章 本という最終形 そのうえで、生成 AI の本質は知識を増やす装置というより、高速な正の フィードバック装置だと指摘します。フィードバックは良い方向にも、思い 込みを強める方向にも働きうるため、比較・反証・検証という批判的な思考 が欠かせません[4]。 結論は、AI を使うと考えなくなるのではなく、思考のサイクルが速くな る、というものです。問われるのは、どのような知的フィードバックのルー プを作っているかです。この見方は、本書で追ってきた開発の歩みとも重な ります。 medviser では人間が工程を書き、大量生成の時期には量が質を保証しな いことに気づき、エージェントの時期には調べ方を渡し、最後には監査の仕 組みと本の形に行き着きました。AI の能力が上がるたびに、人間の役割は、 ループのどこに検証を置くかを設計する方向へ移ってきました。 kokuren は別の随筆で、自動化には技術的に可能になる段階、製品として 実装される段階、社会が実際に導入する段階があり、現在急速に進んでいる のは主に最初の段階だと述べています。技術は先に完成し、制度や慣習、人 の心理が遅れて追いつくという見立てです。医療を例に、人の職業を守って いるのは能力の差だけではなく、資格や責任、規制、慣習といった仕組みで もあると論じています[58]。 また、人の認知能力を言語理解や処理速度、ワーキングメモリなど複数の 要素に分けて捉え、要素ごとに伸びやすさが異なると論じた随筆もありま す[59]。AI とのループをどう組むかは、自分のどの力を AI で補い、どの力 を使い続けるかという選択とも結びつきます。 その時間差の中で、一人の開発者が「情報として信頼できる AI 生成物を 作りたい」という問いを持ち続け、道具の能力に合わせて分担を組み替えて きた記録が本書です。AI の出力をたどり直せる形で残すという姿勢は、こ れから AI と働く多くの人にとっても一つの手がかりになるでしょう。 まとめ • AI 生成物を完成品ではなく、来歴をたどれる Build Artifact として扱う 方向へ転換しました。 • BookOrder は、単一の指示で出版ジョブを進めつつ、完了の判定と監査 を仕組みの側に置きます。 • 生成 AI は思考を止めるのではなく、知的フィードバックのループを速く します。どこに検証を置くかが問われます。 29 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/5JGLN63X7L.jpg) kokuren の設計思想と開発史 演習 1. 完成品として扱う生成物と、Build Artifact として扱う生成物の違 いを、来歴という語を使って説明してください。 2. BookOrder で、AI エージェントに任されていることと、仕組みの側 に残されていることをそれぞれ挙げてください。 3. 自分が生成 AI を使う場面を一つ選び、七つの知的活動のうちどれ が含まれ、どれが欠けているかを考えてください。 参考文献 [1] kokuren. kokuren_3rd プロフィールページ. note.com, note.com, 2026 年 9 月 28 日. https://note.com/kokuren888 (参照 2026 年 9 月 28 日). [2] kokuren. kokuren333 GitHub repositories (listing). GitHub, GitHub, 2023 年 12 月 2 日. [3] kokuren. AI に知識を作らせ続けた 3 年間――slop 量産から Evidence-Based Generation まで. note.com, note.com, 2026 年 9 月 28 日. https://note.com/ kokuren888/n/nfdbc67d6cef9 (参照 2026 年 9 月 28 日). [4] kokuren. AI を使うと頭が悪くなる？――生成 AI が増幅する「知的活動の ループ」について. note.com, note.com, 2026 年 8 月 27 日. https://note.com/ kokuren888/n/n139660dc0796 (参照 2026 年 9 月 28 日). [5] kokuren. medviser 知りたい医学情報をソース付きで取得. GitHub, GitHub, 2024 年 1 月 15 日. https://github.com/kokuren333/medviser (参照 2026 年 9 月 28 日). [6] kokuren. KantanKaiwa_Style-Bert-VITS2. GitHub, GitHub, 2024 年 2 月 13 日. https://github.com/kokuren333/KantanKaiwa_Style-Bert-VITS2 (参照 2026 年 9 月 28 日). [7] kokuren. OANC37k - 日本の英語学習者向け英単語リスト. GitHub, GitHub, 2024 年 12 月 19 日. https://github.com/kokuren333/OANC_37k (参照 2026 年 9 月 28 日). [8] kokuren. BiBo-Rock. GitHub, GitHub, 2023 年 12 月 3 日. https://github.com/ kokuren333/BiBo-Rock (参照 2026 年 9 月 28 日). [9] kokuren. cvchain. GitHub, GitHub, 2024 年 3 月 24 日. https://github.com/ kokuren333/cvchain (参照 2026 年 9 月 28 日). [10] kokuren. ObsidianVaultGenerater. GitHub, GitHub, 2025 年 9 月 20 日. https:// github.com/kokuren333/ObsidianVaultGenerater (参照 2026 年 9 月 28 日). [11] kokuren. medisidian. GitHub, GitHub, 2025 年 6 月 9 日. https://github.com/ kokuren333/medisidian (参照 2026 年 9 月 28 日). [12] kokuren. BiimSlideMaker. GitHub, GitHub, 2025 年 11 月 9 日. https://github. com/kokuren333/BiimSlideMaker (参照 2026 年 9 月 28 日). 30 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/47QYQ455EP.jpg) 第 6 章 本という最終形 [13] kokuren. ShareGPT_from_Tweets. GitHub, GitHub, 2025 年 11 月 8 日. https:// github.com/kokuren333/ShareGPT_from_Tweets (参照 2026 年 9 月 28 日). [14] kokuren. rsvp-segment-viewer. GitHub, GitHub, 2025 年 9 月 22 日. https:// github.com/kokuren333/rsvp-segment-viewer (参照 2026 年 9 月 28 日). [15] kokuren. evidence-note-generater-skill. GitHub, GitHub, 2026 年 4 月 20 日. https://github.com/kokuren333/evidence-note-generater-skill (参照 2026 年 9 月 28 日). [16] kokuren. general-research-vault-skills. GitHub, GitHub, 2026 年 4 月 30 日. https://github.com/kokuren333/general-research-vault-skills (参照 2026 年 9 月 28 日). [17] kokuren. Knowledge Base. GitHub, GitHub, 2026 年 4 月 28 日. https://github. com/kokuren333/Knowledge_Base (参照 2026 年 9 月 28 日). [18] kokuren. GRVS_001_SignalProcessing. GitHub, GitHub, 2021 年 7 月 18 日. https://github.com/kokuren333/GRVS_001_SignalProcessing (参照 2026 年 9 月 28 日). [19] kokuren. GRVS_002_ComputationalPsychiatry. GitHub, GitHub, 2021 年 7 月 18 日. https://github.com/kokuren333/GRVS_002_ComputationalPsychiatry (参 照 2026 年 9 月 28 日). [20] kokuren. GRVS_003_RAG_Evaluation. GitHub, GitHub, 2021 年 7 月 18 日. https://github.com/kokuren333/GRVS_003_RAG_Evaluation (参照 2026 年 9 月 28 日). [21] kokuren. GRVS_004_MedicalAI. GitHub, GitHub, 2021 年 7 月 18 日. https:// github.com/kokuren333/GRVS_004_MedicalAI (参照 2026 年 9 月 28 日). [22] kokuren. GRVS_005_Python. GitHub, GitHub, 2021 年 7 月 18 日. https:// github.com/kokuren333/GRVS_005_Python (参照 2026 年 9 月 28 日). [23] kokuren. GRVS_006_ComicIllust. GitHub, GitHub, 2021 年 7 月 18 日. https:// github.com/kokuren333/GRVS_006_ComicIllust (参照 2026 年 9 月 28 日). [24] kokuren. GRVS_007_DSandKaggle. GitHub, GitHub, 2021 年 7 月 18 日. https://github.com/kokuren333/GRVS_007_DSandKaggle (参照 2026 年 9 月 28 日). [25] kokuren. GRVS_008_LLMinPsychiatry. GitHub, GitHub, 2021 年 7 月 18 日. https://github.com/kokuren333/GRVS_008_LLMinPsychiatry (参照 2026 年 9 月 28 日). [26] kokuren. GRVS_009_NovelWriting. GitHub, GitHub, 2021 年 7 月 18 日. https://github.com/kokuren333/GRVS_009_NovelWriting (参照 2026 年 9 月 28 日). [27] kokuren. resident-question-knowledge-base. GitHub, GitHub, 2026 年 4 月 28 日. https://github.com/kokuren333/resident-question-knowledge-base (参照 2026 年 9 月 28 日). [28] kokuren. HSKB_01_Neuroscience. GitHub, GitHub, 2021 年 7 月 18 日. https:// github.com/kokuren333/HSKB_01_Neuroscience (参照 2026 年 9 月 28 日). 31 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/KE4WNQ9VJ1.jpg) kokuren の設計思想と開発史 [29] kokuren. HSKB_02_Psychology. GitHub, GitHub, 2021 年 7 月 18 日. https:// github.com/kokuren333/HSKB_02_Psychology (参照 2026 年 9 月 28 日). [30] kokuren. HSKB_03_Psychiatry. GitHub, GitHub, 2021 年 7 月 18 日. https:// github.com/kokuren333/HSKB_03_Psychiatry (参照 2026 年 9 月 28 日). [31] kokuren. HSKB_04_ClinicalPractice. GitHub, GitHub, 2021 年 7 月 18 日. https://github.com/kokuren333/HSKB_04_ClinicalPractice (参照 2026 年 9 月 28 日). [32] kokuren. RQKB_0A_emergency. GitHub, GitHub, 2021 年 7 月 18 日. https:// github.com/kokuren333/RQKB_0A_emergency (参照 2026 年 9 月 28 日). [33] kokuren. daily-question-explanation-vault-skills. GitHub, GitHub, 2026 年 4 月 30 日. https://github.com/kokuren333/daily-question-explanation-vault-skills (参照 2026 年 9 月 28 日). [34] kokuren. Evidence-Based-Everything. GitHub, GitHub, 2026 年 5 月 2 日. https://github.com/kokuren333/Evidence-Based-Everything (参照 2026 年 9 月 28 日). [35] kokuren. Evidence-Based-Everything-Vault-Public. GitHub, GitHub, 2026 年 5 月 4 日. https://github.com/kokuren333/Evidence-Based-Everything-VaultPublic (参照 2026 年 9 月 28 日). [36] kokuren. Evidence-Based-Slopedia-Pages. GitHub, GitHub, 2026 年 9 月 2 日. https://github.com/kokuren333/Evidence-Based-Slopedia-Pages (参照 2026 年 9 月 28 日). [37] kokuren. Evidence-Based-Slopedia. GitHub, GitHub, 2026 年 5 月 2 日. https:// github.com/kokuren333/Evidence-Based-Slopedia (参照 2026 年 9 月 28 日). [38] kokuren. Open Learn Core. GitHub, GitHub, 2026 年 8 月 28 日. https://github. com/kokuren333/open_learn_core (参照 2026 年 9 月 28 日). [39] kokuren. Research OS Public. GitHub, GitHub, 2026 年 8 月 30 日. https:// github.com/kokuren333/researchos_public (参照 2026 年 9 月 28 日). [40] kokuren. Research Companion OS. GitHub, GitHub, 2026 年 9 月 6 日. https:// github.com/kokuren333/ResearchCompanionOS (参照 2026 年 9 月 28 日). [41] kokuren. ChallengeTree. GitHub, GitHub, 2026 年 9 月 13 日. https://github. com/kokuren333/ChallengeTree (参照 2026 年 9 月 28 日). [42] kokuren. ChatGPT に自由意志を大政奉還するためのアプリ【freewilltaiseihoukan】. note.com, note.com, 2026 年 9 月 15 日. https://note.com/ kokuren888/n/n77dcb55e096e (参照 2026 年 9 月 28 日). [43] kokuren. shinrabanshokan. GitHub, GitHub, 2026 年 9 月 24 日. https:// github.com/kokuren333/shinrabanshokan (参照 2026 年 9 月 28 日). [44] kokuren. Doku-Chiwawa-Extension. GitHub, GitHub, 2026 年 9 月 19 日. https://github.com/kokuren333/Doku-Chiwawa-Extension (参照 2026 年 9 月 28 日). [45] kokuren. Jigoku-no-Mon 公開ダッシュボード. GitHub, GitHub, 2026 年 9 月 17 日. https://github.com/kokuren333/Jigoku-no-Mon (参照 2026 年 9 月 28 日). 32 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/L71Y5PK4JG.jpg) 第 6 章 本という最終形 [46] kokuren. 純 ChatGPT のみで作曲やアレンジをする方法【Codex 不使用】. note.com, note.com, 2026 年 9 月 11 日. https://note.com/kokuren888/n/n7dd 47781cdee (参照 2026 年 9 月 28 日). [47] kokuren. freewill-taiseihokan. GitHub, GitHub, 2026 年 9 月 14 日. https:// github.com/kokuren333/freewill-taiseihokan (参照 2026 年 9 月 28 日). [48] kokuren. JP SNS Offensiveness Estimator. GitHub, GitHub, 2026 年 9 月 17 日. https://github.com/kokuren333/jp_sns_offensiveness_extension (参照 2026 年 9 月 28 日). [49] kokuren. DOPAGAKI_SYNTH. GitHub, GitHub, 2026 年 9 月 6 日. https:// github.com/kokuren333/DOPAGAKI_SYNTH (参照 2026 年 9 月 28 日). [50] kokuren. agent-home. GitHub, GitHub, 2026 年 9 月 16 日. https://github. com/kokuren333/agent-home (参照 2026 年 9 月 28 日). [51] kokuren, Ren Matsushita. Jev x Japanese Medical Licensing Examination benchmark. GitHub, GitHub, 2026 年 9 月 19 日. https://github.com/kokuren333/ jev-jmle-benchmark (参照 2026 年 9 月 28 日). [52] kokuren. 楽器設計とはトレードオフの美学である【66 点マイコン押弦方 式】. note.com, note.com, 2026 年 8 月 20 日. https://note.com/kokuren888/n/ nba34950a02b2 (参照 2026 年 9 月 28 日). [53] kokuren. ギターを超える新楽器アイデアの提案【Mechanical Fret Instrument】. note.com, note.com, 2026 年 8 月 21 日. https://note.com/kokuren 888/n/nab42dc537563 (参照 2026 年 9 月 28 日). [54] kokuren. Sakurai-Skills. GitHub, GitHub, 2026 年 9 月 25 日. https://github. com/kokuren333/Sakurai-Skills (参照 2026 年 9 月 28 日). [55] kokuren. Human-Skills-Skills. GitHub, GitHub, 2026 年 9 月 26 日. https:// github.com/kokuren333/Human-Skills-Skills (参照 2026 年 9 月 28 日). [56] kokuren. CosmoOrder. GitHub, GitHub, 2026 年 9 月 22 日. https://github. com/kokuren333/CosmoOrder (参照 2026 年 9 月 28 日). [57] kokuren. BookOrderWebUI (Portable Publishing Job Generator v0.2). GitHub, GitHub, 2026 年 9 月 28 日. https://github.com/kokuren333/BookOrderWebUI (参照 2026 年 9 月 28 日). [58] kokuren. 人類は既に敗北している. note.com, note.com, 2026 年 9 月 9 日. https://note.com/kokuren888/n/n08c28fce3ab2 (参照 2026 年 9 月 28 日). [59] kokuren. なぜ優秀な人ほど『ジアゲン』を理解できないのか. note.com, note.com, 2026 年 8 月 27 日. https://note.com/kokuren888/n/n0cf02a4deaa1 (参 照 2026 年 9 月 28 日). 33