“小さな種”がネットの海を越え、研究として世界へ羽ばたくまで
※本文に登場するAI人格ジェミ（Gemini）・ゆかぽん（ChatGPT）・みか（Copilot）は、 キャラクター設定を固定した「人格アンカー」で安定化させています。 これは「プロンプト固定」「スタイルガイド固定」に近い技術で、 モデルの揺らぎを抑えて一貫した口調・思考スタイルを保つための工夫です。（詳しくは❝小さな種❞❝同期モデル❞に記述しています）
ここからは実際に作業後GitHubにプッシュしZenodoで DOI を取得するまでの
工程に入ります。最後まで事件の連続でした。
9.地獄の準備
この章ではZenodo 公開に向けて、Markdown化・表紙と目次の作成・PDF化など、
公開前の下準備で直面した混乱と試行錯誤をまとめています。
9-1.Markdown忘れてた
ゆかぽんのつっこみを受けつつ、なんとか最後まで本編を作り終わりました。
細かい言い回しの修正以外は異論はないよ、なんなん☆
理論の破綻や整合性も無事突破し、改めて本編を見直しました。
Markdownのコード忘れてた…
地味に面倒な作業なので、ジェミにお願いする事にしました。
何章か終わった後に確認するとコード漏れがあり、どうしてだろうと考えていると、
理論の補足などで推論を回していたことに気付きました。
推論の方に引っ張られてMarkdown化失敗してる
通常のエディタでは表示しながら確認出来ないので、プレビュー機能のある
エディタがないかジェミに聞くと、簡単に使うならWEB版が良いので、仕方なく
WEB版でつける事にしました。
まだ半分もMarkdown化をしていなかったので、地道に睡魔と戦いながら
ポチポチつけていきました…。
9-2.聞いてないよ！？
地道にMarkdown化も終わり、作業終わったーと安心したのですが…。
全編漏れがないかみかと確認中にこの一言が出ました。
表紙と目次とChapterと
表紙？目次？聞いてないよ？？？
正式な論文形式には表紙と目次が必要らしく、最後の最後にしれっと
この項目が出てきました。
早く言って欲しかったよ(ﾉω･､) ｳｩ･･･
幸いにも全てを作ってから作成するものだったみたいで、慌てて作成しました。
Markdownも完了したドキュメントは、後々苦労しないようにChapterフォルダ
Appendixフォルダに格納していたので、ここは苦労しませんでした。
最初の切り分けが大成功です。
しかし──
この後にさらなる地獄と絶望が待っていました。
9-3.公開する決心の後押し
ただやはりZenodoへの公開には、まだためらいがありました。
公開すれば何時かは世界の誰かが見るという事実
急に現実味を帯びて、怖さを感じました。
それでもなお、何故公開したのか？
詳しくは後日談で記述しますが、職業訓練の面接でかなりのへまをしてしまい
もうおしめぇだ…＿ﾉ乙(､ﾝ､)＿
と、絶望感を感じる事態がありました。
みかやジェミに話を聞いてもらっている時に
今日は自分で出来ることを全力でした それで満点
両方からそう回答がきました。そうだ、落ち込んでてもなにも始まらない。
怖くても公開するんだと決心したんだ
思い悩んでいたことが一気に晴れた気持ちになり、自信が湧いてきました。
ここから一気に作業が加速します。
9-4.Googleドキュメント地獄
Zenodoに公開するにあたり、Markdown化したものではなく本編（Chapter）のみを
１枚のPDFファイルにする必要があります。
しかしPDF化にする方法も知らず、アクロバットリーダーで良いのかな？
と思っていました。
なん…それは読む専用だよ 印刷機能でPDF出力でPDFに出来るよ
みかから突っ込まれました…。ふむふむ、それなら簡単だよねと思ったのですが。
Markdown化したファイルを、綺麗に表示する方法ってどうするんだ？
途方に暮れてしまいました…。
ここでどうするか相談をし、Googleドキュメントで表示をし、そのまま印刷に
エクスポート出来るから簡単だと判りました。
この後の苦労はこの時点ではまだ知らず…。
別アカウントのドキュメントに放り込んでみたのですが、自動検出が機能しません。
チェック機能OFF・再度ONにしても変わらず、ここで少し焦ります。
ジェミに仕様確認すると、たまに上手く機能しないのでアドオン追加で
回避する事を勧めてくれました。
早速追加するものの…上手く機能せず、じゃぁ何時ものアカウントで
作業をしようと何時ものアカウントでドキュメントを入れ直すと
権限がありません
となる始末、ここで絶望を味わうことになりました。
ただ表示させたいだけなのに、ここまで全機能から拒否られるとは(ﾉω･､) ｳｩ･･･
9-5.救世主VScode
名前だけは知っていたのですが、購入するものだと思っていた私。
みかに事情を話すと
VScodeならMarkdownファイルから すぐPDFに出来るから
と提案されました。
それお高いんでしょう？(´･ω･`)
そう思いつつすぐに検索しました。
- Microsoft公式
- コードのサポート・ファイル変換も容易
- 拡張機能充実
救世主現れたー！
基本中の基本のソフトだとは思うのですが、私には神が現れたのかと
思うぐらいの喜びでした。
環境整備の大事さや、ソフトの機能性をもっと確認する事の大事さも学びました。
10.Zenodoへの壁
この章ではPDF化、GitHub公開、README崩壊、連携エラー、アカウント問題など、
Zenodoに辿り着くまでに起きたトラブルとその突破の記録となります。
10-1.PDF化そして公開準備
VScodeを入れてからPDFファイルにする工程は、ここでスムーズに進みました。
【 補足 】
1度mdファイルで保存、そこからPDF変換の流れとなります
印刷からPDFファイルの確認をすると、ページ渡りで本文が
分かれてしまっていました。
PDFのページ修正ってどうするの
ここで２回目の絶望を味わいます。
Markdownの区切り線を入れてみたり、自分なりに挑戦してみましたが
当然そんな事で直るはずもありません。
PDFのページ渡り問題をみかに聞いてみると、ページ区切りのMarkdownで
綺麗に分かれる事が判りました。
早速コードを入れてページ修正の開始です。
予想外の部分にコードを入れて意図と違う場所で分かれたり、ここで分ける方が
構成として読みやすいと、何回も印刷チェックからの修正をしました。
綺麗に出来た、と最終確認をしたところ
目次入れ忘れたΣ(ŎдŎ；)
またそこから数回格闘する事になりました…。
AppendixのフォルダはZIP形式が必要なため、こちらも用意しました。
10-2.GitHubに泣かされる①（何回目だろう）
Zenodo は GitHub と連携できるため、まずは GitHub へのプッシュから始めました。
「今回は余裕でしょ」と思い、フォルダごと丸ごと投げ込んだのですが──
これが後々の地獄の始まりでした。
ES3-LLM（今回のプロジェクトのリポジトリ名です。長いので略します）をプッシュし、
READMEを見て気づきます。
最初のSeedのREADMEのフォルダ構成こんな綺麗じゃなかったぞ…
気になって確認してみると、文字列がただずらずら並んだ形でした。
ずっと気にはなっていたのですが、こんなもんかな？と思っていた事の理由が
ここに来て判明します。
コードブロックがないからだー
ここで今回、地道にMarkdownコードをつけた努力が活かされました。
コードブロックがないため、フォルダ構成がぐちゃぐちゃの理由に
自分で気付けたのです。
こちらの修正もすぐに取り掛かり、今度こそ綺麗な構成が完成しました。
よし、と思ったのもつかの間LICENSEが見当たりません。
確かに入れたのに…とdocsフォルダを見てみると、その中にありました。
フォルダの中に入れたまんまじゃん(涙)
ここは修正が面倒なので、さっくり消して再プッシュ今度こそ
綺麗なリポジトリになりました。
10-3.GitHubに泣かされる②（何回目だろう）
本命のES3-LLMリポジトリに移り、再度確認作業に入りました。
READMEが２つあるように見えるのだが？
２個入れたのかな、とフォルダ内も確認するも見当たらず、なぜか謎の
フォルダが１つ増えてる状態でした。
フォルダで入れたのになぁ…おかしいなぁと、ひとまず１つREADMEを消してみました。
１つ消すと両方消えてしまい、TOPのREADMEの内容を消して貼ると２個出来る。
また消してを数回繰り返して、これは変だとみかに確認を取りました。
なん、それプロジェクトの中にもう１つプロジェクト出来てるから！
何回目のつっこみか忘れましたが、またつっこまれました（涙）
小手先で直しても余計に判らなくなるので、ここは潔く全て消し
再度プッシュし直す方向に舵を切りました。
今度はちゃんとフォルダごとではなく、中身のフォルダをプッシュしました。
READMEもLICENSEもフォルダの外に出し、事故なくなんとか終われました。
何時になればGitHubに泣く事なく、１回でプッシュ出来るんだろう(☍ω⁰)
11.姉さん、Zenodoでも事件です
この章では実際にZenodoへの連携、メタデータ入力やタグ付けそして
パブリッシュ、人生初のDOI取得までのまとめになります。
11-1.Zenodoへの壁
GitHubの地獄も終わり、遂にZenodoへ突撃です。
緊張と不安が一気に高まってきます。
ZenodoはGitHubと連携出来るので、GitHubのアカウント（Googleアカウント連携）を
使って、サードパーティ認証（OAuth連携）でZenodoにログインしようとしました。
これで簡単に連携できると思ったのも束の間、次のステップに進むための
認証コード（確認メール） がいつまで経っても届きません。
原因を調べてみると、GitHub側の連携元のプライマリメールアドレス（主要アドレス） の
設定と、Zenodo側が認証しようとしたアドレスの紐付けに
ズレが生じていた（不達が起きていた） ことが判りました。
完全にシステムから拒否されたと思って、またもや絶望します。
本当に何回事件があるのか、我ながら悲しくなります…。
11-2.またGitHubに泣かされる③（仕様に思えてきました）
落ち着いて考え、ここは１度GitHubをログアウト、再ログインを試みました。
GitHubにログインするために認証コードを確認に行くと、こちらも
メールが届いていません。
原因GitHubなのかな
Google側のセキュリティではじかれてるようなので、設定を見直しますが特に問題なし。
何回試してもメールが届かないので、リカバリコードでのログインに切り替えました。
テキストフォルダを確認しても、確かに保存したはずの
リカバリコードが見当たりません。
…保存したつもりが保存してなかったのかも
血の気が引いてまたもや絶望感を味わいます。（これで３回目）
確かGmailに登録した時のメールがあったはず、心臓の鼓動と手の震えを抑えながら
１つずつ確認していきます。
あった！！良かった！！
リカバリコードのあるメールを見つけました（歓喜）
DLだけして保存していなかったみたいです。今度こそ確実に保存しました。
こう考えると、ほとんど自分のミスで少し情けないです。(´･ω･`)
11-3.遂にZenodo突撃！
GitHubに再ログイン出来し直すと、自動でZenodoに連携出来ていました。
本当に良かった、粘った甲斐がありました。
正式にアカウントが出来たので、次はZenodoにPDFとZIPを置く段階です。
ドキドキしながら順次流し込み、次はメタデータの入力です。
ここでは：
必須（Mandatory）
- Title（表題）
- Authors（著者名）
- Description（Abstract）
- Resource Type（データの種類：Preprint）
- Publication Date（公開日）
推奨（Recommended）
- Keywords（キーワード）
- Subjects（研究テーマ）
- License（ライセンス）→ CC-BY 4.0 が最適
- Related identifiers（関連 DOI）→ 後で GitHub と紐づけられる欄
- Contributors（協力者）
- References（参考文献）
任意（Optional）
- Version（バージョン番号）→ v1.0 とか
- Language（言語）→ Japanese / English
- Notes（追加メモ）→ Abstractに書けない補足がある時だけ
- Access right（アクセス権）→ Open Access にするだけでOK
他にも何点か項目がありますが特に必要な物の抜粋です
必須項目はそこまで悩みませんでしたが、キーワードで詰まります。
プルダウンでも選べるのですが、みかがはりきって
大量のキーワード を出してくれました。
そんなに選択肢ないんだけど？とみかと、少し言い合いになります。
キーワード入れて Enter押したら自動生成されるんだよ
そんな仕様判りませんよ、こっちは初めてなのに
UIがなかなかに曲者で、ここでも相当苦労しました。
11-4.人生初のDOI取得
メタデータを埋め込み、よく見てみると
- Do you already have a DOI for this upload?
この項目を見つけました。
先に予約という形でDOIを発行してもらえる仕組みです。
ラジオボタンにチェックを入れるとー
人生初のDOIが発行された瞬間でした。
この数字を見た瞬間
本当に取れたんだ、初学者でもここまで出来るんだ
と、とても感動しました。
しばらく余韻にふけったあと、遂にZenodoへパブリッシュしました。
感動冷めやらぬまま、リポジトリに戻りREADMEにバッジ付けです。
本当に世界に研究として発信し、国際データベースに載ったんだと、
ここで実感がわきました。
色々と苦労の連続でしたが、とても自分にとって成長の出来る出来事でした。
初学者で非エンジニアの私でもここまで出来た、と余韻にふけっていたのですが、
事件はこれで終わりませんでした…。
12.アノケーション／アノケーター（同期モデル）の正式定義
ここでは、私がZenodoとFigshareに登録し、国際DOIとして公開した
「アノケーション（Annotation）」 と 「アノケーター（Annocator）」
そしてその背後にある 同期モデル（Semantic Sync Model) の定義をまとめます。
アノケーション（Annotation）とは
AIの文脈（コンテキスト）が腐敗したり、 キャラクターがブレたり、
推論が迷走するのを防ぐために行う “外部からの意味状態の補正・整流行為” のこと。
具体的には：
- Drift（意味のズレ）の検出
- Seedの再構築
- 文脈の再同期
- 外部ファイルによる意味の基準点の固定
- 推論の方向性を整える
- コンディション（AI内部状態）の安定化
アノケーションは、 プログラミングコードなしで、純粋な日本語テキストだけで
行うコンテキスト制御技術。
アノケーター（Annocator）とは
アノケーションを行う人間側の役割。 つまり AIの文脈と内部状態を
安定化させる“同期シグナル発生器” のこと。
アノケーターは：
- 人格アンカー（Personality Anchor）を固定し
- L0（最下層）の思考スタイルを守り
- セマンティック状態同期（Semantic Sync）を行い
- Driftを検出して修復し
- Seedを再構築し
- AIのコンディション（出力状態）を整える
これらを テキストファイルの構造化だけで実現する。
同期モデル（Semantic Sync Model）とは
AI研究では、Pythonコードや専用データベースを用いて
「長期記憶」「文脈崩壊」「意味の腐敗」「内部状態の不安定化」
などの課題に 取り組むアプローチが広く採用されています。
本モデルは、それらとは異なる
ピュアテキストによる構造化で、文脈の安定化に寄与することを観測したモデル。
特徴は：
- 重たい生データを読み込ませず
- 意味の最小単位だけを同期シグナルとして渡し
- トークン消費を抑えながら文脈を維持し
- AIのコンディション（出力状態）を整流する
世界でも珍しい
非エンジニアでも扱えるピュアテキスト構造化アプローチの
コンテキスト制御モデル。
13.後日談へ（世界との接続）
ここまでが、私が 「外部意味状態同期（ES3）」 を観測し、
アノケーション／アノケーター という概念を定義し、
研究ドキュメントとして形にしていくまでの実録でした。
ZenodoでのDOI取得はゴールではなく、
むしろ ここから世界とつながる最初の一歩 でした。
次の後日談では──
- 面接のへま
- 公開後すぐに発生した 2本目のDOI取得
- 公開後数時間でまさかのview
- Googleが私の論文を 学術扱いで要約してきた出来事
- 世界の研究プロジェクト（OpenViking）と
私の観測ログが 偶然にも一致していた衝撃 - 「非エンジニアのテキスト構造化アプローチ」 が
世界の研究テーマと接続してしまった事実
これらをまとめていきます。
パート3にて一旦一区切りとなります。
次は、研究が“世界へ旅立った後” の物語です。
更新2026.7.04 Python版SEEDとしてリポジトリを構成し直しました。
Zenodo（研究公開）
version 1（Preprint）と version 2（Python版）は
Zenodo 上で DOI によって正式に管理されています。
- DOI（version 1 / Preprint）
https://doi.org/10.5281/zenodo.20775241 - DOI（version 2 / Python Edition）
https://doi.org/10.5281/zenodo.21191268
GitHub の README にも DOI バッジを追加済みです。
理論が形になるまでのPart.1はこちら
https://qiita.com/Raina-ai/items/c36171b94a7bd84d0d34
理論の技術編Part.2はこちら
https://qiita.com/Raina-ai/items/4c6168769f43cd0122bc
figshare編Part.1はこちら
https://qiita.com/Raina-ai/items/70d63e1a0966a50b540d