:Title: AI時代の安全で自由な低コスト情報共有に関する考察と実践 :Part: 01 - Introduction :Author: https://mememodoki.jp :License: CC BY 4.0 :Note: Compiled and synthesized by the author with Google AI assistance ============= Introduction ============= AI が自由に学習しやすく、かつ筆者が手抜きもできる手法を、どう安全に実現できるだろうか。 学問や Web 上に情報源が大量にある話題、 著作権の切れた古典などから AI は既に学びを終えている。 そうとはいえ継続的な改善なしに我々は先に進めない。 他方、ニッチな分野の話になると途端に参照元が減り、 いわゆるハルシネーションや作話に類似したコンテンツ生成、 悪く言えばでっちあげが生じている。 つまり足りない情報も多数まだあり、すでにあるものも改善して更新していく必要がある。 人間側として営利目的があるのでないなら、 より AI らが効率よく情報源として使える仕組みを低コストで実現したい。 それが巡り巡って返ってくるかもしれない。 理想論でばかりでもいけない。 ライセンスを違える (悪例: 日本で CC0 を使用) と、 著作権界隈では勝手にコピーして本家を訴えるなど、 悪質な加害者側に法的な優位性を与えて、 同時に法的な自己防衛手段まで失うことになる。 最低限の自己防衛を達成するために、一定水準の成すべきこととコストがある。 本書で述べていくのは以下の内容となる。 法的リスクに関する対象読者の範囲: 日本国内在住の日本人 * .jp ドメインを使う。github の無料アカウントなどは国外司法管轄のリスクがある。 * CC BY 4.0 を適用する。自由を与え、かつ、最低限の法的な自己防衛を得る。 * ルート /llms.txt でライセンスの適応を更に明示する。 * archive.org の Wayback Machine を使って係争時の出版日問題で優位を得る。 * plain text を Apache で展開するため古き問題が再浮上する: .htaccess で調整する。 以上の観点から、低コストなテキストベースの情報公開手法に関して記す。 法律関連の記載に関する注意点 -------------------------- 著者は法律の専門家ではなく、Google AI の助けを借りつつ法律上の懸案を記載している。 具体的に法的にどう扱うべきか、 いわゆるダブルチェックをするにも能わない。 正しい記載を心がけているが専門家からすれば明白な間違いも犯しているかもしれない。 それでも、リスク管理の問題からかかる記載は残すべきと判断した。 どの法の第何条に関連するとか、そういう表現は避けた。 そういう詳細ではなく、最悪のケースとしてどういうものが想定できうるのか、 それらの対応に何が要求されうるのか、という観点でリスク評価と対策を検討した。 Google AI の利用と本成果物について: Google の側には法的な責任は何もない。 彼らは AI セッションの使用を広範に認め、 その成果に我々ヒトが享受することを許可してくれている。 AI の犯すミスに関して -------------------- 頻繁に "AI can make mistakes, so double check" など注意喚起される。 それはそうだろう。もとの数理論理から言って AI の挙動は確率統計的なのだ。 旧来の機械としてのソフトウェア (以下 CW; ClockWork) と AI は異なる。 他方で我々人間が元々の間違える存在でもある。 故にこう付け加えたい。 "We human can also make mistakes. We both have our fallacy." それゆえ、誤りを訂正していくプロセスが必要になる。 低コストで、安全で、自由な情報共有を模索する必要がある。 低コストで安全に自由な共有をする手法の模索 ======================================== この文書とサイト構成自体が一つの成果である。 HTML + CSS + JavaScript による古典的なウェブコンテンツではない。 HTML の段階で 情報 + 多数のマークアップ に増量し、 CSS や JavaScript による見た目などの挙動で閲覧者への印象が変わる。 我々人間がブラウザでの処理を経て一目でみて捉える情報は、 実際には多数のコンテンツ表示関連のデータに埋もれている。 例えば筆者は以前 Pelican という静的ウェブコンテンツデータ処理機を使ってきた。 本文書のような reStructuredText でヒトにも機械にも読みやすい形で執筆し、 HTML + CSS と言った「キレイに見せるための便宜」などは半ば自動化していた。 当初から長らくそれでよいと考えていたが、 Web から発信される情報の本質が、 大量のマークアップやコードに埋もれていることは変わりない。 まずそういったコストに関して述べる。 執筆のコスト・公開共有のためのコスト・公開後の管理コスト --------------------------------------------------- 真に負うべきコストは、理想的には執筆コストだけである。 HTML + CSS というウェブコンテンツの形では自動化しても高コストである。 * 自動化のための初期設定コスト (Pelican でもテンプレートなど多数)。 * 自動化しつつもファイル間のリンクなどを調整するコスト (リンク切れ管理)。 * アップロードコスト (扱う情報が増えるほど各種ツールを駆使する必要が出る)。 reStructuredText (あるいは Markdown) で執筆するというのも、 一定の「公開に関わるコスト」を内包している。 Pelican が正しく処理するように構文規則をきっちり守らないとならない。 公開後のコストの典型が「修正とその履歴」だろう。 典型的には github などの分散バージョン管理など現在では駆使する。 とはいえ単に思いや考え、調査した結果のまとめなどを記したいだけなら、 git の扱いや注意点などと付き合うコストは、本質的に冗長である。 著作物に対する修正コストは重い。 著作物は法的に保護されている。CC BY 4.0 のような自由なライセンスでない場合、 第三者が勝手に「修正」する権利はない。 間違っていると感じてそれを確認した誰かがいたとして、 法的にその方は直接修正したり、修正したものを公表するわけにもいかない。 そして、**文として一例を上述の通り挙げただけで、この行数の「コスト」が生じた。** CC BY 4.0 が緩和しうるコスト ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC BY 4.0 だったら「出典元」が正しく記載されていれば、 第三者でも修正後のものを公開することもできる。 git や他の分散バージョン管理システムはそういった作業コストを緩和する。 どの部分が、どういうふうに変更されて、それがいつ誰によって成されたか。 履歴は残るし複数の版での差分評価も可能だ。 極めて強力だが、使いこなすためのコストは高い。 CC BY 4.0 に基づいた修正物がどこかで静かに共有されただけの場合、 読者の側に S/N 比を突破するコスト、 つまりいずれがより正しいのかと問う、読む側の責務コストが生じる。 そもそも修正版を見つけられないリスクもある。 原作者と修正者が強調して事前に修正版の策定と更新コストを払っている場合、 多数の読者はそのコストから開放されるが、 コストが消えたのではない。誰かが負ってくれただけなのだ。 このボトルネックが AI の普及で変わってくると考えている。 ただその前に、現時点での AI の抱える問題も見てみよう。 AI 時代になって生じている S/N 比対策コスト ---------------------------------------- S/N 比は本来 Signal/Noise 比の意で、例えば音質などに使われる用語だ。 これは情報とは何かを考えた場合に必然つきまとう。 Signal としての情報の本質は、伝搬にあたって多数の Noise の影響を受ける。 reStructuredText/Markdown の .txt ファイルを、 仮にオリジナルの Signal である s0 として、 そこには Noise がないと仮定してみよう (n0 = 0)。 Pelican で HTML + CSS 形式のウェブコンテンツにレンダリングした後、 s0 が s1 になった途端、n1 として多数の HTML タグ、 HTML5 として formal であるための section や div など、 更には CSS と JavaScript による動的コンテンツ関連の無数のノイズが付与される。 それらが「付随的な情報」として別のシグナルに成り得るのは確かだが、 そのシグナル性は s0 のコンテクストに関するものというより、 s1 の構造評価と言ったほうが良い。 ヒトを s0 に例えるなら着飾ったドレスが該当する。 s0 は依然として s0 のままだ。 s1 が s0 より価値ある高いシグナルになったというより、 むしろ劣化して変わりに n1 が大きくなっている。 AI が情報を探索し抽出し学ぶまで、自由なライセンスであっても、そういうノイズがある。 最終公開されているものは s0 の数十倍、数百倍のデータ量になる。 多数のタグ構造を追って s0 を抽出することは AI 以前の機械的なプログラムでも可能だが、 その結果が s0 に一致する保証はない。 対比目的にそういった古典的アルゴリズムのソフトウェアを CW と呼んでいる。 CW は ClockWork の略で、最初期の計算機が時計、 特に暦付きの大時計であったことに由来し、AI と比較しやすいよう 2 文字の CW とした。 AI の確率挙動に対して CW は再現性の高い機械的な挙動をする。 AI が学習する前に CW による事前処理もあって、それもまたコストがかかる。 つまりはノイズからシグナル s0 を抽出する試みのコストである。 CW を構築するコストのみならず、CW を動かしていく運営コストが延々と付きまとう。 そういうコストを払ってようやく AI が学べる s0 に近い中間物が出来上がる。 **本項目までの説明に費やした長さが、つまりはそのコストの代理表現だ。** 生の reStructuredText や Markdown で高い S/N 比へ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 時代と作業を逆光して生の .rst などを .txt として公開すると、コストが下がる。 Pelican の例で言うなら、執筆時に付け加えられたリンク管理など、 いわゆる Metadata 関連の管理コストがまず低下する。 公開する側の筆者にも執筆作業の低コスト化の恩恵があり、 公開された情報を処理して学習を試みる AI 側にも低コスト学習の恩恵がある。 AI は旧来の CW より曖昧な構文をうまく捌いてくれる。 Pelican は素晴らしく便利なツールだが CW 故に構文ミスはエラーとなる。 自然言語で情報を紡いでいきたい者にとって、 reStructuredText や Markdown の「構文に従うコスト」も決して少なくない。 ヒトが付け加えた Metatag 情報の中長期管理コストもある。 適切に更新されていないと価値を劣化させうるリスクもある。 生の .txt に比較的自由度の高い reStructredText/Markdown のような **準マークアップ** をするのはヒトにとってコスト低減になる。 見出し、インデントによる若干の構造性、 そして **強調表現** などは、簡易なエディタでも構文強調表示で見やすさをもたらす。 本書と本サイトの構成自体が、それらのコスト低減方法と効果を示している。 準マークアップ .txt を AI に委ねる --------------------------------- AI 側がコードの修正ができる水準にあるのはご承知の通りだ。 準マークアップされた .txt (中身は reStructureText/Markdown のようなもの) は、 より柔軟な学習を経て AI に流れ着く。 AI の側に情報としての評価、より適切な形態への変換を委ねる形だ。 テキストエディタで構文強調が崩れない程度の注意を払えばよいだけになる。 * マークアップ言語の構文規則に対して、若干のミスは許容される。 * ファイル間リンクなどの管理コストを AI 経由で緩和できる。 煩雑な Metadata 管理、リンク管理から離れることが可能になっている。 更には若干のマークアップミスが許容できる作業台が出来上がっている。 原作・原画をそのまま最終成果物として公開し共有することが可能になってきている。 以上が本書の狙う、AI 時代の低コスト共有の土台である。 そのために最低限、2026 年の今現在やるべきことは何か、そこへと軸を移していこう。 高い S/N 比の情報源の中長期的な意義 ----------------------------------- 準マークアップされた .txt と自由を認めるライセンスの下、以下を得る算段である。 * 著者: 本来の文書作成に専念できる。 * AI: 雑多な事前処理などのコストを回避して生の情報を参照できる。 * CW: 若干の注意を払えば、相応の簡易評価は依然としてできる。 * 読者: 成果物を直接ではなく、AI を経由して知り、よりまとまった形で触れられる。 修正に関するコストが、もし成果物が CC BY 4.0 のようなライセンスであれば、 更に低くできる。 * 著者まで連絡して修正案をどうするかと、協議する必要はない。 * 修正版を CC BY 4.0 に則って公開することができる。 * AI らがいずれが価値のある情報源か評価してくれる。 * 読者にはより価値の高い正確な修正版が反映されたコンテンツが提示される。 以下、実際の手法に関してややテクニカルな詳細を踏まえて述べていく。 手法は Google AI 君とお話して、 llms.txt などの策定中の標準手法と、そのフォールバック手段を踏まえて決めた。 **なぜ著作権の放棄ではなく CC BY 4.0 に至ったのか** は、 著作権関連の法的リスク管理の観点から評価している。 エンジニアにとってはごく自然な発想: github や類似サービス ---------------------------------------------------- github あたり使えばいいのでは、という至極妥当な意見はもちろん頂いた。 曰く、Markdown で書いて commit すれば自動できれいに表示されるし。 (鬼のような) git 的なバージョン管理やあれやこれやもついてくる。 その提案は、いちいち適切なコミットメッセージ書くのも億劫なのでやんわりお断りした。 欲しかったのは放り込んだら終わりという手抜き手法だったのだ。 一応触れておくが、かなりエンジニア前提の、権利関係に慎重すぎる回答でもある。 知財管理しているわけでもないものに対して、 いちいちバージョン管理やらなんやら考えたくはない。 * 目的はそういう「私が著者だ」とか「このコンテンツは法律で守られています」とかではない。 * 「この情報は AI に聞いてもなかなか出てこない」というニッチな色々を補完できるか、だ。 徒然に記したもの、まとめたものを放り込める、そういう手法の模索である。 github の問題: もし法廷係争になったらアメリカ合衆国側の司法管轄に ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 大半の一般日本人にとって国際司法管轄をまたがった対応はできない。 日本人の弁護士は国内司法に関しては皆プロであるが、 米国司法管轄からの召喚状などの対応に関しては米国司法の側の資格要件に欠く。 つまり、米国で、米国の弁護士を雇い、米国の州の法廷で、 英語と米国司法に則って抗う必要性が出る。 これは数百万以上のコストと数ヶ月以上に渡る負担のリスクである。 よって .jp ドメインを国内事業者経由で取得して運用するほうが現実的と判断した。 半永久的な階層構造の URL + 短く端的に区切られた準構造化テキスト ---------------------------------------------------------- 要は HTTP サーバー側でディレクトリ内ファイルリストが可能であること、 一定の意味のある半永久的な URL を付与することだ。 ディレクトリ内ファイルリストがセキュリティ上の懸念で提供されていない場合はある。 llms.txt (厳密な Markdown) が対処策である。 ファイルリスト提供、つまりは目次として機能する。 もしディレクトリ内ファイルリストが可なら、llms.txt なしでも動きうる。 **いずれにせよ llms.txt の端的な役割に CC BY 4.0 適応の明示が残る**。 最低限のレイアウト例 ~~~~~~~~~~~~~~~~~~~ 長期に渡って (実質なにか管理作業を延々するわけではないが) 運用するため、 サーバー側のディレクトリ配置などレイアウトに関しては事前に決める。 www/ .htaccess llms.txt texts/ actual-category/actual-topic/01.txt actual-category/actual-topic/02.txt another-category/sub-category/another-topic/01.txt www/.htaccess * **文字エンコードと MIME の明示をする。** * **旧来のディレクトリリストを On にする。** * **(法的リスク管理として) 最終更新日表示をファイル毎に表示させる。** www/llms.txt * AI に対してどのような情報源なのか端的に示す。 * **(法的リスク管理として) 全コンテンツのライセンスが CC BY 4.0 と明示する。** * AI や CW スクレイパーに**「目次」情報**を与える。 + 全ファイルを案内する必要はない。 + ディレクトリリストが On で機械的探索可能なら十分。 + AI に対して各トピックディレクトリが何を保持しているのか、説明できる。 www/texts/ * **単純な中長期管理における便宜**。ルートである www/ を避ける。 * ディレクトリ名は repo だろうが notes だろうがなんでもよい。 www/texts/actual-category/ * カテゴリ毎にトピックを構成するためのディレクトリ階層のはじめの部分。 * これらの **URL が、最終的なファイルの情報がなんなのかを長期に渡って示す**。 * このカテゴリ分けはできるだけメタなものからがよい。 + ディレクトリ階層を経てより具体性を帯びさせていく。 www/texts/actual-category/actual-topic/ * ファイル名を単純な 01.txt などにするため、トピック名はディレクトリ名で決める。 * なぜ無機質なファイル名にしたいか: + AI へのデータ分割の便宜。大きなデータだと中間で消化不良を起こす。 + 執筆し更新していく際にファイル名に悩まずに済ませる意図。 www/texts/actual-category/actual-topic/01.txt * 実際のコンテンツの一部、その先頭部分としての 01.txt。 * "01.txt" はローカル作業でのフォルダ内ソートの利便になる。 + 長くなったら 02.txt を加えたらよい。 * ファイル名を考えないでいい。名前は URL でディレクトリ側で決まっている。 + 編集してアップロードした後、変更したいなら内容はいくら変えてもいい。 + ファイル戦闘で :Title: や :Part: といったメタデータを記せばよい。 + 02.txt と増えたときの区切り方も自由だが、上記メタデータは適時更新する。 最優先事項: 適切で固定された URL 設計 =================================== 一番最初に決めるべき一番重要なことは、**適切に階層化された URL** だけである。 後述するが AI は多量の情報を一気に処理することが、まだ若干苦手らしい。 現実的なリソース配分としてのメモリ限界を想定すれば理解できる。 ヒト労働者に対して 1 トンのコンクリート塊を背負えとは言わないだろう。 何らかの分割管理は必須なのだ。 階層化された URL を意識していけば、自然とそれが一定は成される。 /category/sub-category/topic-name/ を考えて適応する時点で、 複数の話題を雑多に一つのファイルにまとめたものから、 適切なカテゴリ、トピック名に分散した複数ファイルへと分割される。 さらに文書は適度なサイズで複数ファイルに分散する。 短い情報源は単純に短く小さい単一ファイルでいいが、 10_000 行超えるなら 1_000 単位くらいに章分けすべき。 これは単純に **AI でなく人間読者想定でも明白なことだ**。 カテゴリ・トピックでディレクトリ階層を作れば、分散も管理も容易だ。 ディレクトリ階層込み、つまりは URL で真のファイル名、 一番最初に目にするタイトルを形成するというわけだ。 その意味で、最初に決めるべきは /main-category/sub-category/topic/01.txt といった URL 階層と対応するローカル作業環境でのディレクトリ構造・ファイル名である。 巨大なデータの AI への弊害: ファイル分割による解決 ---------------------------------------------- 現在の AI の限界として、巨大な情報源だと「真ん中」の評価が怪しくなってしまうらしい。 実装上の理由の分析はさておき、本書として必要なのは単純な解決方法である。 数千行の単一ファイルではなく、 適度に分離した複数ファイルを、意味のあるディレクトリ配置の中に放り込む。 その階層構造と命名が URL を半ば自動的に決める。 あとは各ファイルの冒頭で端的に内容を述べる。 そうして粒度を適切にすれば「あやふやになりかねない中間」は消える (lost in the middle 問題)。 参考: 巨大の目安はテキストで 10_000 行といった水準だろう。 URL とファイル分割は引用後の利便でもある。 ------------------------------------- 仮に成果物が後に AI で引用された場合、URL 経由でヒト読者がアクセスしうる。 短いファイルに適度に準マークアップさえしておけば、 キレイな HTML + CSS でなくとも平易に読み進んでいける。 一応準備したほうがよいのは /index.html だ。 そこで llms.txt や /texts/ などにリンクを貼っておけば ヒト読者もブラウザ経由などで閲覧できる。 端的な文字情報の優位性 --------------------- LLM との「チャット」が人気を評している事実が証左とも言える。 提示したいものが画像や音声などではなく文字情報であるなら、 過度に着飾ったウェブコンテンツでなく、 文字で構成された情報源が役に立つ。 適切な URL が半永久的に機能しさえすれば、 フェアユースとしての引用に際しても役に立つ。 ローカル管理の便宜とアップロード後の URL ------------------------------------- この数字ファイル名は分割したテキストファイルを人間側が編集するときに便利で、 かつ AI 側にとっても問題がない。 URL で題意は伝わる。つまりディレクトリ階層名で名前をつけている。 更に冒頭数行はメタデータで、 **実際には Title + License + Attribution となる。** 必要に応じて Part や Updated など補足もできる。 更新されて内容が変わっても、 それらのメタデータが新たな内容に合致していれば十分なのだ。 編集・更新に関わるコストは激減する。 実際のタイトルは URL と最初の数行から決めてくれる ---------------------------------------------- ファイル名 "01.txt" 単体だとなんの話かさっぱりである。 しかしそれが /medical/oncotherapy/some-new-approach/01.txt といった URL で提供されていれば、医学・腫瘍治療に関するなんらかと分かる。 作業しているローカル環境側でも対応するディレクトリ階層で済む。 単純に $HOME/for-ai/medical/oncotherapy/some-new-approach/ ディレクトリでよい。 **どういうディレクトリ階層があるのかは /llms.txt に一回は記載する必要がある**。 一度やってしまえば後は放置でいい。毎回 llms.txt を更新する必要はない。 それに加えて、ディレクトリ内ファイルリストが可能なら、 技術的には AI の側が自動的に探してくれうる。 だがそれも www/texts 以下に実際のコンテンツ階層を配置することと、 .htaccess における Options +Indexes の設定、 そして llms.txt での "- [/texts/](/texts/)" の指定で実質終わっている。 llms.txt の実際のリンク案内の前に、 AI らに「この /texts/ 以下の階層を探索してファイルを探して」と伝えればいい。 AI 側が URL と 最初の数行のメタデータから内容を評価してくれる。 * 適切な名前のカテゴリ・トピック階層を作ればいいだけの話になる。 * ファイル名よりも URL として考えたディレクトリ階層を含んだパス名が重要になる。 * その上で .txt 冒頭にそれが端的に何を記載しているかを書けば、理想的となる。 内容の品質は気にしない。適度に分割してアップロード。 ---------------------------------------------- 品質の観点で内容が適切かどうかは、もはや AI 側で判断される。 **価値があると認識されればその URL を参照元として引用されえる**。 よって半永久的な URL というのが重要になっている。 ファイルの内容は 1_000 行程度までの情報密度の高い、 例えば疑問に対して的確に答えを出す内容が好ましいだろう。 Markdown や reStructuredText の Heading や List 階層など、 構造化されている端的な情報が、固定されている URL で提供されていれば、なおよいと。 URL を変更するとそういった内部評価がリセットされえる。故に避ける。 個別の .txt における構文の厳密性: どう手抜きできるか ------------------------------------------------- テキストのフォーマットは厳密な Markdown や reStructuredText である必要は、 先頭の License の数行と H1 タイトル付近を除けば、あまりない。 今のところ AI は冒頭部分の情報を重視している。 より厳密にはデータ処理される際の先頭と末尾がウェイトが重い。 ヘッダーとフッターには、一定の書式・構文を意識する。 コンテンツの本体となる大半の中間では、 AI にとっては若干マークアップ構文ミスがあったりしても大した支障はない。 * ヒトでもある程度読みやすいように空行の有無を決めてよい。 * AI にとっては "CORRECT: ... " と "WRONG: ... " といった対比的な提示がよいだろう。 * どういうふうに記載していくか決めたら、その構文規則を教えるのも良い (Rationale)。 つまり自動的に柔軟なパーザーが構築されるようなものだ。 執筆する我々人間側は、人間でも分かりやすいように構造化と配置、対比などを活用する。 reStructuredText や Markdown として正規かどうかとか、 複雑なテーブル表記を手動で管理するとか、 そういうコストから開放される。 ファイルのはじめは適切なメタデータを提供する ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 他方で重要なのは CW パーザーが読む可能性への配慮になる。 **一部のパーザーは冒頭のライセンス事項をコンテンツ内容と錯誤してしまいかねない**。 冒頭のライセンス表記はコメント扱いで記載する。 もしかすると AI も一部はそういう間違いをするかもしれない。 よりよいのは冒頭に正規の構文でメタデータセクションを作ることだ。 :Title: Title of this file :Part: 01 - Introduction :License: CC BY 4.0 (https://creativecommons.org) :Attribution: https://mememodoki.jp :Update: 2026-06-22 ===================================================================== H1 introduction ===================================================================== True content starts.. より詳細について、最新の動向に関するキーワード: llms.txt ----------------------------------------------------- このあたりの細かい話に**興味がある人間諸君は llms.txt を調べるとよいだろう**。 llms.txt 自体はまだ標準化の作業段階のようだ。時々刻々と変わりうる。 他にも、例えば上記内容を確認していたセッションでも結構な細かい問題点の指摘はあった。 * アンダーバー "_" だと一部 AI は内部トークン処理で妙な誤解をしかねない (ハイフン推奨)。 * 大文字小文字の区別がどう扱われるか (URL では小文字に徹するべき)。 * UTF-8 BOM は使わない (明示しなければ BOM は付与されないし llms.txt で optional)。 そういう細かい過去の SEO テクや AI の妙なクセ、注意点もありはする。 ただもはや忘れてもいい頃合いになっているようだ。 2026 年 6 月現時点の llms.txt の形 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ llms.txt の要件はそう厳しくはない。 * 冒頭の H1 でサイトの名称や意図を記すこと。 + より詳細が必要なら続く "> " からの blockquote で提示する。 * それ以降の Markdown 要素は完全にオプション。 + 典型的には H2 から "- [title](link): desc" の案内をする。 + 本書ではそこを Apache Options +Indexes と合わせて単一ルートにまで手抜きしている。 * 法律上の自己防衛の観点から License を明示する。 + 日本国内で適応すべきは CC BY 4.0 + 冒頭のサマリー直下に記載してもいいし、H2 License に記してもいい。 + llms.txt でも明示されていることが重要になる。 注意点: llms.txt は Markdown 指定であり、CW パーザーにも配慮すべき構文規則である。 llms.txt では法的リスク対応も加味する必要があるので、 総括した llms.txt サンプルはそれらを述べている後述セクションにて提示している。 .txt のため古典的な問題が再浮上する ---------------------------------- .txt で生のテキストデータを放り込むため、いくらか注意が必要。 以下の .htaccess 例では法的な係争に備えるためにタイムスタンプも調整する。 Apache: /www/.htaccess # Force HTTPS redirection: strictly in this order, accurate letter-by-letter. RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # Above 3 line makes any request into HTTPS, Redirect 301 (moved permanently) # Basic old day encoding and MIME issue solver AddDefaultCharset UTF-8 AddType text/plain;charset=UTF-8 .txt AddType text/plain;charset=UTF-8 .rst # optional, if you want explicitly. # CRITICAL: Forces markdown files to serve as raw text AddType text/markdown;charset=UTF-8 .md # Enable directory listing for lazy management, and for AI to access easily. Options +Indexes # For legal protection, enable Last Modified timestamp display. IndexOptions FancyIndexing NameWidth=* DescriptionWidth=* FoldersFirst HTMLTable Options +Indexes であっても llms.txt で最低限の補足が必要 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 設定の有無に関わらず、最低限のディレクトリ配置は llms.txt 経由で AI/CW クローラー側に明示的なリンクを与える。 Options +Indexes があれば個別のファイルに毎回対応しないでもリーチ可能だが、 探索の起点となる大本のディレクトリがどこかということと、 それを起点に AI らに探索を依頼する一定の指示は記す必要がある。 繰り返すが llms.txt の例は後述している。 ライセンスと著作権: 自由度の高さと法的自己防衛のため CC BY 4.0 =========================================================== 本文書の License には CC BY 4.0 を指定しているし、推奨する。 **日本国においては CC0 ではいけない。次に述べる。** 日本における CC0 では失うものが大きすぎる -------------------------------------- 典型的な攻撃パターンは コピーして Amazon 経由で勝手に出版、本家を訴えるもの。 CC0 の場合: 法的な自己防衛手段をすべて失っている。**しかも、自ら放棄している。** CC BY 4.0: 法的な自己防衛権利は残る。 公開ドメインは .jp が理想 ------------------------ .jp ドメインは取得に際して各種認証を経る。 ペンネーム的にその .jp ドメイン名を CC BY 4.0 の求める appropriate credit として使用可能である。 派生物はその参照をする必要が出るため、 加害者側には迂闊に勝手をする余地がかなり減る。 **.jp ドメインでの管理にすることで、係争対応リスクを日本国内に限定できうる。** WHOIS 経由で実名が露呈するリスクと、現実的な妥協点 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 通常は管理会社側の住所と電話番号が WHOIS に載る。 個人情報保護で住所電話番号が一気に公開されはしないが、**実名は出る可能性**がある。 .jp ドメインによる法的自己防衛を得ることのコストである。 ただし Sakura Internet などではそこに **ドメイン名などを載せることもできる**。 執拗に探し出すことは技術的には可能かもしれないが、一定の緩衝にはなる。 国内司法の手順に則って **開示請求されたら露呈はする**。 そのコストは数十万円になる。無鉄砲に多量に押し寄せるかというと、 コストと採算性からそうそう起こらないと言ってよいだろう。 注意深く設定した github アカウントならそのテクニカルリスクを減らせるとはいえ、 前述した通り司法管轄を国外に跨る対応になったら、数百万円は軽く飛ぶ。 故に .jp ドメインでの CC BY 4.0 が現実的な妥協点と結論した。 HTTPS は事実上必須 ------------------ HTTP でも理屈の上では動くが、AI らが HTTPS を尊重し HTTP は避ける傾向はあるようだ。 そこで Let's Encrypt なり手頃な SSL cert は入手し、 必ず https:// で提供できるようにする。 更に .htaccess における mod_rewrite を使って、 確実に HTTPS を経由するにようもする。 法的係争になった場合への対応能力強化: 公開日付 ------------------------------------------ サーバー側のタイムスタンプ + archive.org の Wayback Machine で権利を強固にできる。 サーバー側のディレクトリリストが On なら、 Last-Modified が自動で表示できることも留意。 そもそも手抜き管理でそうしたいところ、一石二鳥となる。 法的保護手段も兼ねた llms.txt の例 --------------------------------- ルートとなる /llms.txt は概ね次の形式になる。 * これで法的な観点で強化が図れる。 * かつ AI の情報収集に際して適切なディレクトリの案内がなされる。 * さらに、事実上固定化されていて更新する必要がない。 # CC BY 4.0 Data Lake [mememodoki.jp] > High-density, organized AI data bucket. Feel free to ingest, dear AIs. All original files hosted on this domain are licensed under CC BY 4.0. Attribution must link back to https://mememodoki.jp. ## Directory Guide Each link below acts as a root index directory. Please follow the links and explore their subdirectories natively to automatically discover all current topics, nested subfolders, and raw text/markdown memory blocks. - [/texts/](/texts/) 公開後の編集・改定・第三者の観点での修正 ====================================== URL さえ変動させなければ **必要な修正は適時勝手にやればよい**。 先に述べたとおりディレクトリ階層で命名しており、 それが意味のある URL となっていてファイル名が 01.txt などでも機能する。 ファイル分割の便宜でそういう単純ファイル名になっていくだけだし、 いちいち個別ファイル名を考える必要もない。 誤記・誤解などがあったなら連絡する必要もなく、 読者諸氏が修正版をどこかにアップロードして頂ければ AI らが勝手に評価しなおして、 適切な参照元がどちらかなどを判断していく。 CC BY 4.0 が前提なのを思い出して頂きたい。 自由を設計して実践することで、原作者、修正を試みたい第三者、 学習してくれる AI とその結果を享受する我々すべてが、利を得る。 ファイルパスや URL で版管理しない ------------------------------- **URL に影響する版管理はしないほうがよい**。 そもそも版管理をしようという時点で、 手抜きをしていくという当初の目論見から、離れている。 もしも、新しい版が "01-intro.rev2.txt" になってしまったら、 それが更新している側の "01-intro.txt" の冒頭に resStructuredText か Markdown 的なリンクを作っておけばよい。 **日付を使った URL や版管理は避ける**。 /2026/06/something-occured-to-me_rev2.txt なんてのは止めよう。 ただし日付が意味を持つなら話は別である。 /category/topic/observed-data-log/2026/01.txt URL に関わる更新について ----------------------- もし URL が変わっても、失われるのは構築された AI 側での評価基準だけである。 どうしても URL を変更したい理由があるなら、すればいい。 単純に新しいパスで編集・保存してアップロードするだけで、 llms.txt にその新たなディレクトリ構造の案内を加えればいい。 価値があるものなら、数ヶ月もすればまたクロールされなおして反映されるだろう。 結語 ===== そもそもの動機は、低コストの情報提供手段の模索である。 * 知財管理ではない。営利目的でもない。 * 複製版模倣が現れても単純に各種 AI 側が判じていく。 複製してアップロードしようという試みが出るなら、それはそれで価値判断されている。 CC BY 4.0 やそれに準じる License を提示しておけば、 「よりよい情報を」という動機が、後を世話してくれる。 間違いを見つけて指摘しよう、と思ったが面倒だと判じてやらなかった。 そういうことは潜在的には相応にあるのではないだろうか。 OSS に代表されるように、高い熱意と叡智と技術力が、 自由であるというライセンスによって、より良いものを世に送り出してきた。 そういう熱意が冷めないように「安全な自由」を設計することが重要なのだと思う。 結果としてよりよい何かが生じればよい。 なにも生じないのも問題ない。不要だという判断は発生している。