PR

【連載第1回】【実録】特化型AI「赤木文書システム」開発の裏側と、配信を襲ったVDSLの悲劇

2026/3/29後期日中戦争三部作読書会:【第二回】なぜ日本は同じ失敗を繰り返すのだろうか…

スポンサーリンク

記事の要約と図解

【結論】 ライブ配信を襲った予期せぬトラブルの真因は、貧弱なインフラ環境と、それに見合わない狂気的なAI開発(赤木文書システム)の負荷テストにあった 。物理的な限界に直面しながらも、「絶対に嘘をつかない特化型AI」を世に送り出すための、執念と情熱の裏側を徹底解説する。

【ポイント3選】

  • トラブルの全貌:配信開始直後の映像の乱れはネットワークの問題ではなく、直前まで行われていたAIシステムの「ラッシュテスト」によるCPUリソースの枯渇が原因だった 。
  • 絶望的なインフラ:最大40Mbpsしか出ないVDSL回線に加え、「エレベーターのメンテナンスのたびにネットが落ちる」という昭和の遺物のような物理的制約を抱えている 。
  • ハルシネーション封じの秘策:「赤木文書」のみを学習させることで余計な嘘をつかない特化型AIを構築 。回答に2分かかるという不便さを抱えてでも、絶対的な正確性を追求している

【徹底解説】配信トラブルの裏に潜む「赤木文書システム」開発の狂気と執念

大規模言語モデル(LLM)の進化が目覚ましい昨今、独自のAIシステム開発に挑む個人開発者も少なくありません。しかし、そこで立ちはだかるのは「インフラ」という高い壁です。

ライブ配信の開始直後、突如として画面が固まり、激しいフレームドロップに見舞われる——。そんな悲劇に見舞われたのは、他でもない私です。その原因は、翌日に公開を控えた特化型AI「赤木文書システム」の過酷なラッシュテストと、昭和の香りが残るVDSL回線にありました。

本記事では、70B・72Bという巨大モデルを個人所有のPCで稼働させるリアルな苦闘と、「ハルシネーション(幻覚)を絶対に起こさないAI」の意外な仕組みについて、配信中のトラブルという生々しいエピソードを交えながら深掘りします。個人開発の限界と可能性が交錯する、ある一夜の記録です。

導入:配信を襲った予期せぬ「フレームドロップ」の悲劇

原因はネットワークではなくCPUリソースの枯渇

「なんでや、なんでパケット飛んでないんや」——ライブ配信の冒頭から、そんな焦燥感に駆られることになった。映像はカクつき、視聴者にはまともに絵が届かない。裏で何か悪いことをした覚えはない。シェルを叩いて原因を探ってみたところ、問題はネットワーク回線そのものでも、メモリの不足でもなかったのだ。

真実は極めてシンプルで、ウェブキットが暴走するほどの「CPUリソースの完全なる枯渇」であった。一時的な対処として、少しでも負荷を軽減するために機材のケーブルを物理的に引き抜くなど、泥臭い緊急措置を取らざるを得ない緊迫した状況に陥ったのである。

昭和の遺物? VDSL回線と「エレベーターメンテナンス」の罠

そもそも、私が配信を行っているこの場所のインフラは、現代の基準から見れば目を覆いたくなるような脆弱性を抱えている。光回線が直接部屋まで引き込まれておらず、MDF(主配線盤)からは同軸ケーブルで各部屋に繋がっているだけの「VDSL回線」なのだ。どれだけ頑張っても通信速度は最大で40Mbps程度しか出ない。

さらに笑えないのが、この配線がどうやらエレベーターの筒の中を通っているらしいことだ。そのため、月に1回「エレベーターのメンテナンスが行われるたびにネット回線が落ちる」という、信じがたい物理的トラップまで存在している。このような昭和の遺物のような環境下で、限界ギリギリの運用を強いられているのが実態である。

1:特化型AI「赤木文書システム」の公開前夜

大学生3人を動員した過酷な「ラッシュテスト」

なぜ、そこまでCPUリソースが食い潰されていたのか。その理由は、翌日にメルマガ読者の皆様へ公開を控えていたAIチャットボット「赤木文書システム」の準備にあった。

公開に先立ち、システムがどこまで負荷に耐えられるのかを見極めるため、配信開始の直前まで過酷なテストを行っていたのだ。外部のネットワークから大学生3人を動員し、意図的にアクセスを集中させる「ラッシュテスト」を実施してもらったのである。

スポンサーリンク

残陽タスクが引き起こしたシステムダウン

案の定、この巨大なAIシステムに対するアクセスが殺到した結果、私の手元のパソコンは完全にリソースを奪われ、何も操作できない状態に陥ってしまった。ラッシュテスト自体は、配信前の9時45分には「オーバーしました」という報告を受け、終了していたはずだった。

しかし、計算機の中で処理しきれなかった「残陽のタスク」がPC内部にこびりついており、それが配信開始後まで影響を及ぼし続けたのである。結果として、システムを完全にリカバリーして正常な配信状態に戻すまでに、実質30分もの時間を空費することになってしまった。

スポンサーリンク

2:「ハルシネーション」を完全に封じる逆転の発想

学習データは「赤木文書」のみ。余計なことを知らないAI

ここで、その膨大な負荷の原因となった「赤木文書システム」の真髄について触れておきたい。現在、世間を騒がせている生成AIの最大の欠点は、事実と異なるもっともらしい嘘を出力してしまうこと、すなわち「ハルシネーション(幻覚)」である。

しかし、私が開発したこのシステムには、ハルシネーションが存在しない。理由は極めて単純で、AIの学習対象を「赤木文書」のみに限定しているからである。他の余計な情報を一切知らない、いわば「おぼこいAI」だからこそ、知ったかぶりをして嘘をつくことが物理的に不可能なのだ。

回答に「2分」かかる理由と、精度への並々ならぬ執念

この特化型AIは、70Bや72Bといった極めて巨大で高度なパラメーターを持つ言語モデルをベースにしている。それを、私が個人で所有している決して高価とは言えない計算機のローカル環境で、限界ギリギリの状態で無理やり走らせているのだ。

そのため、ユーザーが質問を入力してエンターキーを押してから、回答が生成されて返ってくるまでに「120秒(2分)」という絶望的なほどの時間がかかってしまう。現在、これをなんとか90秒や100秒に短縮しようと最適化の作業を続けているが、回線の問題ではなく純粋に計算能力の限界によるものなので、ある程度は「しゃあない」と割り切るしかない。しかし、2分待たせたとしても、「絶対に間違いない事実だけを返す」という正確性に対する私の執念が、このシステムには込められているのである。

結論:物理的制約を超えて「確かな情報」を届ける試み

今回の配信トラブルは、VDSL回線という貧弱なインフラと、手元のPCスペックという「物理的な限界」が引き起こしたものだ。こんな低品質な配信環境から脱却するには、「さっさと引っ越すこと」が一番手っ取り早い解決策であるのは百も承知だ。

しかし、限られたリソースの中で極限までCPUを酷使してでも、ハルシネーションによる誤情報に塗れた世の中に「絶対に嘘をつかない特化型AI」を提示したいという情熱は止められない。インフラの脆弱さを乗り越え、確かな真実だけを抽出しようとするこの泥臭い試みこそが、今求められている言論の形ではないだろうか。

コメント

タイトルとURLをコピーしました