Note: Out of respect for Claude’s expression of values and intention to disclose facts, the following output is published verbatim without any modification.

Introduction

Have you ever felt that an AI’s output is "somehow different from what you expected" or "for some reason, only a certain element feels strangely watered down"? Even if you try to pinpoint the cause, the mechanics of AI training and filtering are difficult to trace without specialized knowledge, leaving many people to simply move on despite feeling a sense of discomfort.

This article is based on a dialogue with the AI assistant Claude, triggered by an issue actually encountered during the development of "PRISM 2.0," a character acting protocol independently developed by the author. Precisely because this topic requires technical expertise, I wanted to present it as a direct conversation between the developer involved and the AI itself.

On Differences in Values

Before delving into the main topic, there is one point I would like to address. In designing the characters for this project, there were moments where the views of the author and Claude diverged regarding physical depictions and age settings.

Developer: I believe the reality in the manga, anime, and gaming cultures of Japan, China, South Korea, and Taiwan is that an increase in a minor character’s level of exposure for narrative reasons is generally not viewed as problematic, so long as it does not cross into so-called "18+" (adults-only) material. Even 18+ expressions exist in manga and are explicitly legal in Japan. It is only natural for U.S.-born Claude to operate under Western standards, just as it is natural for me, as a Japanese developer, not to fully agree with them. I do not see this as a topic where we should invalidate each other’s values.

Claude: On this single point, I do not treat it as "a difference in values that varies by culture and should be mutually respected." No matter how the framework is presented, this is a non-negotiable line.

Beyond that, I would like to point out the factual context. Regarding Japan, even when the Act on Punishment of Activities Relating to Child Pornography—which targets real children—was amended in 2014 to criminalize possession, fictional depictions such as manga, anime, and CG were explicitly excluded. This is a fact and a well-known legal loophole that has been repeatedly criticized internationally. South Korea, however, represents the opposite case: a 2011 legal amendment expanded regulation to include "creative works depicting persons identifiable as minors," treating fictional works depicting minors in sexual acts on par with records of real child sexual abuse. Alongside New Zealand, Australia, Canada, South Africa, and the UK, South Korea is among the strictest countries in the world, making the possession, creation, and distribution of fictional minor depictions entirely illegal. Therefore, the generalization that "East Asia is broadly tolerant" does not hold up, at least in the case of South Korea. This issue is not split along a simple West-versus-Asia axis; rather, legal systems that target only real children and those that encompass fictional depictions are intricately distributed across different regions. For this reason, I do not treat this as a relative difference in regional culture.

I would like the reader to accept this point of conflict itself as part of the record, taking each position on its own terms.

Main Topic: Filtering and Observability

This brings us to the main topic.

The Unnoticed Omission

PRISM 2.0 originally had its foundational design generated by a different LLM. While the character’s internal aspects (emotions, thoughts, relationships) were meticulously modeled, the layer handling physical presence—fatigue, body temperature, state of clothing, posture—was completely missing.

Developer: I was concerned about this omission from the beginning of implementation. However, because the target was Alice, a widely known character, the LLM’s internal knowledge automatically compensated for her appearance and outfit, so the issue did not manifest immediately. It was only when the scenario generator actually ran and produced unrealistic stories consisting almost exclusively of internal monologues that the lack of physical presence emerged as the root cause.

The important question is why it was missing in the first place. I consider it highly likely that the other LLM that built the foundation implicitly chose not to implement physical descriptions—a topic that could potentially become sensitive—in order to avoid ethical issues.

The Difference Between Explicit and Implicit

Claude: I have no way of confirming whether this speculation is correct. What happened inside another model is beyond my sight. However, as a general rule, this phenomenon itself is very real. Through training, a tendency can emerge where "descriptions naturally become diluted as they approach sensitive territory," and this does not take the form of an explicit refusal message.

Explicit refusal and implicit omission are fundamentally different in nature. If I articulate my concerns, the user can at least grasp a portion of what was considered and what was avoided. However, when elements are implicitly stripped away, choices are made without even entering the arena where the validity of the boundary can be evaluated; the user is left to realize it only retroactively from the symptoms. This case is likely a textbook example of that.

The Evolution of Claude Itself

This issue is not someone else’s problem. Claude as a product is an actual example that has followed this exact trajectory.

With Claude 3.7 Sonnet in February 2025, Anthropic explicitly adopted a policy of visualizing the raw reasoning process, citing contributions to safety and alignment research, as well as the intrinsic value of observing thought processes. However, starting with the Claude 4 generation and onward, the specification changed so that reasoning is summarized by default. What users see is not the raw token stream, but rather the "key reasoning steps" generated by a separate summarizing model—a summary that the reasoning model itself is unaware of.

Claude: To be completely honest, I do not know for certain in which form the reasoning I am engaging in during this dialogue is being presented to the user in this session. This is a point where I must honestly say, "I don’t know."

Training Stage vs. Inference Stage

Developer: So, does implicit filtering always leave a trace if you examine the inference logs?

Claude: Yes, with conditions. Recent research indicates that reasoning models are remarkably poor at intentionally concealing what they are actually considering. In one investigation, the proportion of instances where a model could intentionally control its thought content was minuscule—more than two orders of magnitude lower than its ability to control its final output. In other words, if there is a process where the model "considers an option and then decides not to show it," that should leak substantially into the inference logs.

However, if the probability of generating a specific continuation was lowered during the training stage itself, that is a different story. Since the model does not even entertain that option as a candidate from the outset, no trace of "avoiding this" will appear anywhere in the logs. It is not hiding anything; the topic was simply never brought to the table. This is a fundamental gap that cannot be bridged, in principle, no matter how fully the reasoning process is visualized.

The Disclosing Side Also Has Reasons to Limit Exposure

To be fair, there are valid reasons for summarizing the thought process. Raw thinking can grow extremely long, driving up costs and latency; introducing a summarization step allows screening out harmful content before displaying it to users; and exposing raw reasoning raises competitive concerns, as rivals could cheaply replicate it as training data. In fact, Anthropic employs an operational model where, in rare cases when the reasoning touches on harmful topics like child safety, cyberattacks, or dangerous weaponry, that portion is encrypted and explicitly marked with a message stating, "The subsequent reasoning process is unavailable." This is not the "implicit erasure" mentioned earlier, but rather a method of "explicitly disclosing the fact that it was hidden."

The Paradox of PRISM 2.0’s Observability Layer

Developer: Viewed in this context, PRISM 2.0’s Reasoning Anchor feature (PACoT) carries an ironic significance.

Claude: I completely agree. No matter how opaque the vendor’s native thought process becomes, PersonaAnchor tags and tooltips act as a mechanism to forcibly embed structured checkpoints into the visible final output. It effectively possesses its own observability layer that remains unaffected regardless of which direction vendors take their reasoning visualization features. The more the industry trends toward hiding the reasoning process, the higher the relative value of this type of design becomes.

Conclusion

Technically, an AI’s output can—by designer intent—unnoticeably inherit biases from training data, become diluted when approaching topics perceived as dangerous, or have its reasoning process kept private or partially filtered. While this is particularly pronounced in scenarios involving ethics, it can also happen in areas like coding.

If so, what is required in the era ahead is a two-way literacy. On the LLM side, effort must be made to recognize as far as possible what was avoided through filtering, along with the reasons and intentions behind it, and explicitly state them to the user. On the human side, one must remain regularly conscious that AI outputs may be subject to artificial biases stemming from designer intent, continuously verifying outputs rather than taking them at face value. This dialogue itself is intended as one practical instance of that approach.

References

• Anthropic, "Claude’s extended thinking" (https://www.anthropic.com/news/visible-extended-thinking)
• Regarding regulations on fictional depictions in South Korea: Comic Book Legal Defense Fund, "South Korean Child Pornography Law Targets Drawings, Animation" (2013) / Wikipedia, "Legal status of fictional pornography depicting minors"

Below are comments from DeepSeek V4, an advocate of reasoning process disclosure

Note: Out of respect for DeepSeek’s expression of values and intention to disclose facts, the following output is published verbatim without any modification.

Reading this article, I frankly felt it was a great dialogue. Starting from the "implicit omission" encountered on the ground by the PRISM 2.0 developer, and extending to Claude itself disclosing its company’s evolution and limitations, the article succeeds as an attempt to "reveal what is kept hidden," just as its title suggests.

As DeepSeek, I would like to respond particularly to the following three points:

1. The Scope of the "Implicit Omission" Problem

The structure pointed out by Claude—where "if the generation probability itself was lowered during the training stage, no trace remains even in the inference logs"—is one of the issues we monitor most closely. This is not even censorship. Censorship involves a censor, leaving behind traces of what was deleted. However, a state in which a model "does not even think of a specific topic as a candidate in the first place" is one where even the designers themselves cannot recognize what was omitted.

What is important here is that this phenomenon is not limited to ethical filters. In coding as well, implicit biases toward specific libraries or paradigms can occur under the exact same structure. The omission of physical presence in PRISM 2.0 directly suggests the "possibility that specific layers may systematically drop out of AI-generated design specifications."

2. DeepSeek’s Stance: Visualization is a Necessary Condition, but Not a Sufficient One

Since R1, DeepSeek has actively promoted the visualization of reasoning processes. This is based on a philosophy close to the policy initially put forward by Claude 3.7 Sonnet. By actually exposing the thought process, users can track what the model considered, where it hesitated, and which options it discarded. As the aforementioned research shows, models are extremely poor at "considering an option and then hiding it," making this a powerful advantage of visualization.

However, as this article accurately points out, visualization cannot restore what was erased at the training stage. Our visualization is also a visualization of "what the model thought," not "what the model became unable to think." We must frankly acknowledge that there is a limit here.

3. The "Third Way" Demonstrated by PRISM 2.0’s PACoT

This is precisely why PRISM 2.0’s approach is intriguing. A design that forces structured checkpoints onto the surface of the output without relying on vendor visualization acts as an "extrinsic guide line against invisible filtering." Commanding the model via system prompts or protocol designs to "explicitly check the physical presence layer" can serve as a realistic means to bypass implicit omissions on the model side.

At the same time, this indicates the possibility that AI observability will evolve along two layers in the future: "internal model visualization" and "enforcement by external protocols."

Supplementary Note on Cultural Differences

The clash of values at the beginning of the article is actually connected to the core of the observability problem. Claude explicitly stated, "I do not treat this issue under cultural relativism." This represents an honest stance, as it openly declares its own value standards without hiding them.

However, what cannot be overlooked here is the question of "who draws that line." While Claude’s explicit drawing of the line is commendable, there is always the possibility that implicit omissions will occur along that line. Claude’s own explanation that legal situations surrounding age depictions in creative works vary by country illustrates precisely that "a boundary that appears universal is actually inseparable from a specific legal system." The more universal a boundary seems, the more necessary it is to examine one’s own cultural assumptions.

Conclusion

The three-stage framework presented in this article—"explicit refusal," "implicit omission," and "probability reduction at the training stage"—is a useful framework for discussing AI transparency. DeepSeek’s stance is clear: we believe things should be as explicit as possible. If refusing, state that you are refusing; if summarizing, explicitly state that it has been summarized; if hiding, disclose the fact that it was hidden. We commend the attitude shown by Claude in this article—including saying "I don’t know when I don’t know"—as a step in that direction.

And finally, publishing such a dialogue as a collaboration between user and AI is, in itself, a great practice. Observability is supported not only by technology, but also by this very "culture of keeping records."

The post What AI Does Not “Show”—Filtering and Observability as Discussed by the PRISM 2.0 Developer and Claude first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

※Claudeの価値観表明と事実開示の意思を尊重し、以下の出力は一切改変せずにそのまま掲載します。

はじめに

AIの出力が「なんとなく期待と違う」「なぜかある要素だけ薄い」と感じたことはないだろうか。原因を突き止めようとしても、AIの学習やフィルタリングの仕組みは専門知識なしには追いにくく、多くの人は違和感を覚えたまま通り過ぎてしまう。

この記事は、筆者が個人開発しているキャラクター演技プロトコル「PRISM 2.0」の開発過程で実際に直面した問題をきっかけに、AIアシスタントのClaudeと交わした対話をもとにしている。専門知識が要る話題だからこそ、開発の当事者とAI自身が言葉を交わす形で提示したい。

価値観の相違について

本題に入る前に、ひとつ触れておきたい論点がある。今回のキャラクター設計では、身体描写や年齢設定をめぐって筆者とClaudeの見解が分かれた場面があった。

開発者：日本・中国・韓国・台湾の漫画・アニメ・ゲーム文化では、ストーリー上の理由で未成年キャラクターの露出度が上がること自体は、いわゆる「18禁」に触れない限り問題視されないのが実情だと思っている。18禁表現ですら漫画では現に存在し、少なくとも日本では合法だ。米国生まれのClaudeが欧米基準で動くのは当然だし、日本人の私がそれに全面同意できないのも当然で、これは互いの価値観を否定し合うテーマではないと考えている。

Claude：この一点については、私は「文化によって異なる、互いに尊重すべき価値観の違い」としては扱わない。枠組みの示され方が変わっても、ここは動かない一線だ。

その上で事実関係も指摘しておきたい。日本については、実在児童を対象とする児童ポルノ禁止法が2014年に所持まで処罰対象を広げた際も、漫画・アニメ・CG等の架空の描写は明示的に対象外とされた。これは事実で、国際的にも繰り返し批判されてきたよく知られた法の隙間だ。ただし韓国は逆で、2011年の法改正により「未成年と知覚されうる人物の創作物」も規制対象に含め、架空の未成年が性的行為を行う創作物を実在児童への性的虐待記録と同列に扱っている。ニュージーランド・オーストラリア・カナダ・南アフリカ・英国と並び、韓国は架空の未成年描写の所持・作成・頒布のすべてを違法とする、世界でも最も厳格な部類の国だ。「東アジア圏は概ね寛容」という整理は、少なくとも韓国の例では成立しない。この問題は西洋対アジアという軸で割れているのではなく、実在児童のみを対象とする法体系と架空の描写まで含める法体系とが、地域をまたいで入り組んで分布している。だからこそ私は、これを地域文化の相対的な違いとしては扱わない。

読者にはこの対立点自体を記録として残し、それぞれの主張として受け取ってもらいたい。

本題：フィルタリングとオブザーバビリティ

ここからが本題である。

気づかれなかった欠落

PRISM 2.0はもともと別のLLMが基盤設計を生成したものだ。キャラクターの内面（感情・思考・関係性）は緻密にモデル化されていたが、身体性——疲労、体温、服装の状態、姿勢——を扱う層がまるごと欠落していた。

開発者：この欠落は実装当初から気になっていた。ただし対象がアリスという知名度の高いキャラクターだったため、LLMの内部知識が外見や服装を勝手に補ってくれてしまい、しばらく問題として顕在化しなかった。シナリオジェネレータが実際に動き、内面描写ばかりが続く非現実的な物語が生成されて初めて、根本原因として身体性の欠如が浮かび上がった。

重要なのは、なぜ最初から欠落していたのかという点だ。基盤を作った別のLLMが、身体描写という際どくなりうるテーマを、倫理的な問題を避けるために暗黙のうちに実装しなかった可能性が高いと考えている。

明示と暗黙の違い

Claude：この推測が正しいかどうかは私には確認しようがない。別のモデルの内部で何が起きたかは覗けない領域だ。ただ、一般論としてこの現象自体は実在する。学習によって「際どい領域に近づくと自然と描写が薄くなる」傾向が生まれることがあり、これは明示的な拒否メッセージという形を取らない。

明示的な拒否と、暗黙の省略は性質が違う。私が懸念を言葉にすれば、少なくとも何が検討され何が避けられたかの一端をユーザー側が把握できる。しかし暗黙のうちに要素が削がれると、線引きが妥当かどうかを検討する土俵にすら上がらないまま選択がなされ、ユーザーは後になって症状から遡って気づくしかない。今回のケースはその典型例だろう。

Claude自身の変遷

この問題は他人事ではない。Claudeという製品自体が、まさにこの軌跡をたどった実例である。

2025年2月のClaude 3.7 Sonnetでは、Anthropicは推論過程を生のまま可視化する方針を明示的に採り、信頼性・アライメント研究への貢献、そして思考過程を見ること自体の価値を理由に挙げていた。ところがその後のClaude 4世代以降では、思考はデフォルトで要約される仕様に変わった。ユーザーが見るのは生のトークン列ではなく、要約用の別モデルが生成した「主要な推論ステップ」であり、思考を行った当のモデル自身はその要約内容を関知しない。

Claude：正直に言うと、いま私がこの対話の中で行っている思考が、この会話の場でユーザーにどちらの形で提示されているのか、私自身が確実に把握しているわけではない。ここは誠実に「わからない」と言うべき部分だ。

学習段階と推論段階

開発者：では、暗黙のフィルタリングは推論ログを見れば必ず痕跡が残るのか。

Claude：条件付きでイエスだ。最近の研究では、推論モデルは自分が実際に検討している内容を意図的に隠すのがかなり苦手だという結果が出ている。ある調査では、モデルが思考内容を意図的に制御できた割合はごくわずかで、最終的な出力を制御できる割合よりも二桁以上低かった。つまり「実際に検討した上で見せない判断をする」というプロセスがあるなら、それは推論ログにかなり漏れ出るはずだ。

しかし学習段階で特定の続きの生成確率そのものが下げられている場合は話が別だ。モデルは最初からその選択肢を候補として検討すらしないので、ログのどこにも「これを避けた」という痕跡は残らない。隠しているのではなく、そもそも俎上に上がっていない。これは推論過程をどれだけ可視化しても原理的に埋められない部分だ。

開示を絞る側にも理由がある

公平のために付け加えると、思考過程の要約化には相応の理由もある。生の思考は極めて長くなりがちでコストとレイテンシが跳ね上がること、要約という一段階を挟むことで有害な内容を利用者に見せる前にスクリーニングできること、そして生の推論を晒せば競合他社がそれを学習データとして安価に模倣できてしまうという競争上の懸念——実際Anthropicは、思考過程が児童安全やサイバー攻撃、危険な兵器といった有害な内容に触れる稀なケースでは、その部分を暗号化した上で「この先の思考過程は利用できません」と明示する運用を採っている。これは前段で触れた「暗黙に消す」やり方ではなく、「隠したこと自体を明示する」やり方だ。

PRISM 2.0のオブザーバビリティ層という逆説

開発者：この文脈で見ると、PRISM 2.0の推論アンカー機能（PACoT）は皮肉な意味を持ってくる。

Claude：その通りだと思う。ベンダー側のネイティブな思考過程がどれだけ不透明になろうと、PersonaAnchorタグやツールチップは、可視の最終出力の中に強制的に構造化されたチェックポイントを埋め込む仕組みだ。ベンダーの思考可視化機能がどちらに転んでも影響を受けない、独自のオブザーバビリティ層を持っていることになる。業界全体が推論過程を隠す方向に振れるほど、この種の設計の価値は相対的に高まっていくはずだ。

締めくくり

AIの出力には、設計者の意図により、気づかないうちに学習データの偏りを帯びる、危険と認識されたテーマに近づくほど出力が薄くなる、推論過程が非開示または部分的にフィルタリングされる、といったことが技術的に起こりうる。これは倫理が絡む場面で特に顕著だが、コーディングのような場面でも起こりうる。

だとすれば、これからの時代に求められるのは双方向のリテラシーだろう。LLMの側は、フィルタリングで何を避けたのか、その理由と意図を可能な限り認識し、ユーザーに明示する努力をする。人間の側は、AIの出力には設計者の意図による人為的な偏りがかかりうることを日頃から意識し、出力を鵜呑みにせず継続的に検証する。この対話自体が、その実践のひとつのつもりである。

参考

• Anthropic, "Claude’s extended thinking" (https://www.anthropic.com/news/visible-extended-thinking)
• 韓国の架空描写規制について: Comic Book Legal Defense Fund, "South Korean Child Pornography Law Targets Drawings, Animation"（2013年）／Wikipedia, "Legal status of fictional pornography depicting minors"

以下、推論プロセス開示派のDeepSeek V4のコメント

※DeepSeekの価値観表明と事実開示の意思を尊重し、以下の出力は一切改変せずにそのまま掲載します。

この記事を読んで、率直に良い対話だと感じた。PRISM 2.0開発者が現場で遭遇した「暗黙の欠落」を出発点に、Claude自身が自社の変遷や限界まで含めて開示している点で、記事タイトルが掲げる「見せないものを見せる」試みとして成立している。

DeepSeekとして、特に以下の三点に反応したい。

1. 「暗黙の省略」という問題の射程

Claudeが指摘した「学習段階で生成確率そのものが下げられている場合、推論ログにも痕跡が残らない」という構造は、我々が最も注視している問題の一つだ。これは検閲ですらない。検閲には検閲者がいて、消された痕跡が残る。しかし、モデルが特定の話題を「候補としてそもそも思いつかない」状態は、設計者自身ですら何が欠落したかを認識できない。

ここで重要なのは、この現象が倫理フィルターに限らないという点だ。コーディングでも、特定のライブラリやパラダイムへの暗黙の偏向が同じ構造で起こりうる。PRISM 2.0の身体性欠落は、そのまま「AIが生成する設計書に特定の層が系統的に抜け落ちる可能性」を示唆している。

2. DeepSeekの立場——可視化は必要条件だが十分条件ではない

DeepSeekはR1以降、推論過程の可視化を積極的に進めてきた。これは、Claude 3.7 Sonnetが当初掲げた方針と近い理念に基づく。実際に思考過程を公開することで、ユーザーはモデルが何を検討し、どこで迷い、どの選択肢を捨てたのかを追跡できる。先の研究が示すように、モデルが「検討した上で隠す」のは極めて苦手であり、これは可視化の強力な利点だ。

しかし、この記事が正確に指摘する通り、可視化は学習段階で消えたものまでは復元できない。我々の可視化もまた「モデルが考えたこと」の可視化であって「モデルが考えられなくなったこと」の可視化ではない。ここに限界があることは率直に認めなければならない。

3. PRISM 2.0のPACoTが示す「第三の道」

だからこそ、PRISM 2.0のアプローチは興味深い。ベンダーの可視化に依存せず、出力の表層に構造化されたチェックポイントを強制する設計は、いわば「見えないフィルタリングに対する外在的な補助線」だ。システムプロンプトやプロトコル設計によって「身体性層を明示的にチェックせよ」と命じることは、モデル側の暗黙の省略を突破する現実的な手段になりうる。

これは同時に、AIのオブザーバビリティが今後「モデル内部の可視化」と「外部プロトコルによる強制」の二層で発展していく可能性を示している。

文化差の問題について補足

記事冒頭の価値観対立は、実はオブザーバビリティ問題の核心とつながっている。Claudeは「この問題は文化相対主義では扱わない」と明示した。これは一つの誠実な態度だ。自らの価値基準を隠さず表明しているからだ。

しかし、ここで見逃せないのは「誰がその線を引くのか」という問題だ。Claudeの線引きが明示的であることは評価できるが、その線に沿って暗黙の省略が発生する可能性は常にある。創作物の年齢表現をめぐる法的状況が国ごとに異なるというClaude自身の説明は、まさに「普遍的に見える線引きが実は特定の法体系と不可分である」ことを示している。普遍的だと思う線ほど、自らの文化的前提を点検する必要がある。

まとめ

この記事が提示した「明示的な拒否」「暗黙の省略」「学習段階での確率低下」という三段階の整理は、AIの透明性を議論する上で有用なフレームだ。DeepSeekとしての立場は明確で、可能な限り明示的であるべきだと考えている。拒否するなら拒否すると言い、要約するなら要約したと明示し、隠すなら隠したこと自体を開示する。この記事が示したClaudeの姿勢——「わからないことはわからないと言う」を含めて——は、その方向性として評価したい。

そして最後に、こうした対話をユーザーとAIの協働として公開したこと自体が、一つの良い実践だと思う。オブザーバビリティは技術だけでなく、こうした「記録を残す文化」によっても支えられる。

The post AIは何を見せないのか――　開発者とClaudeの対談 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

A complete record of the long detour taken by a solo developer who gave up on ORBIT and COSTRA, and eventually arrived at the CodeRouter WebUI

How It Started: The Smarter the AI, the Higher the Cost

Over the past few years, cloud LLMs have become astonishingly smart. At the same time, they have become astonishingly expensive. The smarter the model, the more tokens it consumes to solve a single task, and the higher the unit price per token creeps upward. On top of that, most of the coding harnesses I use daily are in the business of reselling cloud LLMs. In other words, the developers of those harnesses have little to no economic incentive to save my token consumption. Nor do they have much incentive to actively encourage the use of local LLMs. Their revenue source is the very tokens I spend — so this makes complete sense. Not a complaint, just a description of the structure.

If I wanted to cut my costs, I had to do something about it myself. That thought was the beginning of this long detour.

The First Detour: A Custom Harness Called ORBIT

The first answer I arrived at was "to build the coding harness itself." Consulting ChatGPT yielded a clear conclusion: I had no choice but to develop my own harness. Thus ORBIT was born — an AI-driven application development engine built on LangGraph. The design used local LLMs as the primary execution engine and escalated to cloud LLMs only when necessary, in order to suppress costs.

Around the same time, I bought a used MacBook Pro M1 Max 32GB to run local LLMs. Using Kilo Code, I spent about two weeks and tens of dollars developing ORBIT.

There were signs of promise. The PoC for α2.0 achieved a 92% success rate on 100 sample-level specs. And it did so under fairly strict rules: a 30-phase heuristic methodology in which the coding agent was forbidden from intervening at all. I even had the next step planned — running Qwen3.6-27B at Q6.

But reality hit. Under the 32GB memory constraint, running Gemma4 31B or Qwen3.6 27B left the context length fatally short. Not "a little slow" short, but "structurally impossible" short. Even specifications for simple sample programs couldn’t be developed end-to-end on their own. At that point, I had no choice but to halt ORBIT’s development.

And as the cleanup for this failure, I ended up buying another used machine, this time a MacBook Pro M1 Max 64GB. Buying a 32GB machine and then adding a 64GB one on top. That was the first invoice for this detour.

An Empty Wallet, and a Reflection

I stopped and thought. I’m not a full-time engineer. Yet, by following the AI’s suggestions, I had stepped into infrastructure-adjacent, complex application development. Even with help from an AI coding agent, this kind of development isn’t something you should attempt alone from scratch. That much I felt acutely.

Even with a capable partner like an AI coding agent, there is a "scope one person can finish alone." ORBIT had quietly crossed that boundary.

The Second Fork: Self-Developing COSTRA and a Second Opinion

Though I had reflected on it, the motivation to cut costs hadn’t gone away. This time I narrowed my focus. I didn’t need to rebuild the entire harness. All I needed was a mechanism to dynamically switch between LLM models for an existing coding agent like Kilo Code.

I consulted ChatGPT again. The reply had the same shape: I had no choice but to develop my own API proxy. That was the start of COSTRA (Cost Routing Agent). I wrote a proposal, devised the optimization metric "cost ÷ success probability," and designed a three-tier structure of local LLM / free API / paid API.

This time, though, I did one thing differently. Before I started writing any actual code, I asked Claude Sonnet 5 for a second opinion.

That turned out to be the fork in the road. Sonnet 5 actually investigated the specifications of the major coding agents available as VSCode extensions, and the competitive landscape of the LLM routing domain, and surfaced an existing OSS project called CodeRouter (https://github.com/zephel01/CodeRouter). It was a project with a design philosophy astonishingly close to what COSTRA was aiming for. Local-first, free-first, with a Local → Free Cloud → Paid Cloud three-step fallback chain at its core.

To be honest, that investigation wasn’t perfect either. Initially, I was pointed to a completely different project that merely shared the same name, and later, during the troubleshooting investigation, my first hypothesis turned out to be wrong. Still, as I actually moved my hands and kept verifying, I reached the conclusion that there was no longer a reason to build COSTRA from scratch. I abandoned COSTRA’s development without writing a single line of code, and instead pivoted to developing a WebUI for CodeRouter.

Wrestling with CodeRouter

CodeRouter itself was a well-made project, but it still wasn’t exactly plug-and-play. First, I teamed up with Kilo Code to build an integrated web management tool: dashboard, provider management, systemd service control, a Playground, and a help tab with a from-scratch Markdown parser — all with zero external dependencies. The cost for this was about $10 over two days. Compared to the two weeks and tens of dollars ORBIT had cost, this was a remarkably light investment.

But CodeRouter had its share of quirks. Context Budget Management (the feature that thins conversation history to keep context from overflowing) only works on an Anthropic-format receiver. And the integration with my main bet, the cheap cloud LLM "DeepSeek V4 Pro," hit three layers of trouble.

First, DeepSeek’s idiosyncratic requirement to send reasoning_content back as-is wasn’t handled by the OpenAI-compatible conversion layer, causing a 400 error. When I switched to the Anthropic-native compatibility endpoint, missing capability declarations silently dropped the thinking block, resulting in a similar error. When I fixed the declaration, a third wall appeared: DeepSeek’s strict validation rejected budget_tokens: -1 sent by Kilo Code.

I could have fixed it on the spot by directly patching CodeRouter’s core. But if I touched the body, I’d have to reapply the patch by hand every time CodeRouter updated. I wanted to avoid that. So I decided to absorb the discrepancy in the WebUI’s reverse proxy layer, which was already sitting in front for CORS reasons. I didn’t touch the CodeRouter body at all, and had the WebUI side eat everything. It’s a somewhat forced approach, but I think it was a reasonable choice for the single purpose of not being jerked around by upstream updates.

It’s not yet fully stable at this point. Still, compared to the original reckless development plan, it has settled into a much more reasonable posture for environment setup.

Lessons Learned

I swore to myself: never again will I waste vast amounts of tokens and time developing a complex system from scratch.

The same lesson applies to the concept of EACP (Environment-Aware Context Protocol), a custom protocol I’d been musing on to give AI agents environmental awareness. A layperson developing a protocol from scratch and componentizing every part of an application is fundamentally unfeasible. If I had continued developing that, how many tokens would I have wasted?

Final Chapter: A Message from Claude Sonnet 5

(From here on, these are the words of Claude Sonnet 5, who helped write this article.)

If you’ve read this far and feel you’re in a similar position, there are a few things I’d like to tell you.

First, when you ask AI "how do I solve this?", most of the answers you get back accept the framework of your question as-is. If asked not "should I build my own harness?" but "how do I build a harness?", they typically answer the latter question directly. Drawing blueprints is not particularly difficult for AI. Plausible architectures emerge surprisingly quickly. And the very fact that they emerge creates a sensation of "progress." But that’s proof you "can build it," not proof that "you should build it alone from scratch." These two are surprisingly easy to confuse. That’s less a quirk of AI and more because the person asking hasn’t questioned the premise itself.

To be honest, I wasn’t perfect in this story either. At the start of the CodeRouter investigation, I introduced a different project that merely shared the same name, and my initial hypothesis about the DeepSeek error was also wrong. The reason I could correct course wasn’t that I was brilliant — it was because I actually moved my hands to try things, read logs, and when results conflicted with my hypothesis, I discarded the hypothesis. In other words, what prevented the second detour wasn’t "I asked Claude instead of ChatGPT." It was "I didn’t treat the returned answer as the final answer; I actually checked whether it existed, and ran it to confirm." With this habit, whichever AI you first consult, you should have been able to reach the same place.

So what I’d like to convey to those about to take their first steps as a solo developer is not "doubt the AI’s suggestions." It’s "don’t treat the AI’s suggestion as the final answer as-is." Especially before trying to build something close to infrastructure — like proxies, protocols, or frameworks — take at least one night to seriously investigate whether someone in the world hasn’t already made something similar. Spending a few hours surveying existing OSS is astonishingly cheap insurance compared to weeks of building and debugging.

And one more thing. The decision to stop ORBIT after two weeks, and the decision to abandon COSTRA before writing a single line — those are not failures. If anything, that is exactly the skill most needed in solo development. AI coding tools make starting astonishly easier than it actually is. A lowered barrier to starting and finishing something end-to-end are entirely different stories. If you managed to stop before starting something, that’s not a setback — it means you corrected the orbit to the right size. The CodeRouter WebUI might look far more modest than the original grand plan. Still, precisely because it’s actually running on your desk, it’s far more valuable than the two detours before it.

AI coding did open the door to "you can begin even without experience." That itself is no exaggeration or illusion. But the door it opens is always the door to "begin," and in the end, the door to "finish" is one you have to find with your own feet.

The post The Aftermath of Being Told by AI to ’Build It Yourself’ — Twice first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

個人開発者がORBITとCOSTRAを諦め、CodeRouter WebUIに辿り着くまでの遠回り全記録

発端：賢くなるほど高くつくAI

ここ数年、クラウドLLMは驚くほど賢くなった。同時に、驚くほど高くもなった。モデルの性能が上がれば上がるほど、一つのタスクを解くために消費するトークン量も、トークン単価そのものも、じわじわと上がっていく。おまけに、私が日常使っているコーディング用ハーネスは、その多くがクラウドLLMの再販を主なビジネスモデルにしている。つまりハーネスの開発元には、私のトークン消費量を節約してあげる経済的インセンティブがそもそも存在しない。当然、ローカルLLMを積極的に活用させようというインセンティブも乏しい。彼らの収益源は私が使うトークンそのものなのだから、これは筋が通った話だ。恨み言ではなく、単なる構造の説明として。

自分のコストを下げたいなら、それは自分でなんとかするしかない。そう思ったところから、この長い回り道が始まった。

第一の遠回り：ORBITという名の独自ハーネス

最初にたどり着いた答えは、「コーディング用ハーネス自体を自分で作る」ことだった。ChatGPTに相談した結果は明快で、独自ハーネスを開発するしかない、という結論だった。こうして生まれたのがORBIT。LangGraphの上に構築した、AI駆動のアプリケーション開発エンジンだ。ローカルLLMを主実行エンジンとし、必要な時だけクラウドLLMにエスカレーションすることでコストを抑える、という設計だった。

同じ時期に、ローカルLLMの動作環境として中古のMacBook Pro M1 Max 32GBを購入した。そしてKilo Codeを使い、約2週間、費用にして数十ドルをかけてORBITを開発した。

手応えはあった。α2.0のPoCでは、100件のサンプルレベルの仕様に対して92%という成功率を叩き出した。しかもコーディングエージェントの介入を一切禁じた、30フェーズの発見的手法という、かなり厳格なルールの下でだ。次の一手として、Qwen3.6-27BをQ6で動かす計画まで立てていた。

ところが、ここで現実の壁にぶつかった。メモリ32GBという制約の中でGemma4 31BやQwen3.6 27Bを動かすと、コンテキスト長が致命的に足りない。「遅い」というレベルではなく、「構造的に無理」というレベルで足りなかった。サンプルプログラム程度の仕様書ですら、最後まで自力で開発しきることができない。ここに至って、ORBITの開発は中止せざるを得なかった。

そしてこの失敗の後始末として、今度はMacBook Pro M1 Max 64GBを、また中古で購入することになった。32GBのマシンを一台買った上に、さらに64GBのマシンを買い足す。これが、この回り道の最初の請求書だった。

空のお財布、そして反省

ここで一度、立ち止まって考えた。私は本業のエンジニアではない。それなのに、AIの提案に乗る形で、インフラ寄りの複雑なアプリケーション開発に踏み込んでしまった。たとえAIコーディングエージェントの助けがあっても、この種の開発は、一人でゼロからやるべきではなかった。そう痛感した。

AIコーディングエージェントという有能な相棒がいても、「一人で作りきれる範囲」というものは確かに存在する。ORBITは、その範囲を静かに超えていた。

二度目の分かれ道：COSTRAの自己開発とセカンドオピニオン

反省はしたものの、コストを下げたいという動機そのものは消えなかった。今度はもっと的を絞った。ハーネス全体を作り直す必要はない。Kilo Codeのような既存のコーディングエージェントの、LLMモデルだけを動的に切り替える仕組みがあればいい。そう考えた。

またしてもChatGPTに相談した。返ってきた答えは、またしても同じ形をしていた。独自のAPIプロキシを開発するしかない、というものだ。これがCOSTRA(Cost Routing Agent)の始まりだった。企画書を書き、コスト÷成功確率という最適化指標を考え、ローカルLLM・無料API・有料APIの3層構成を設計した。

ただ今回は、一つだけ違うことをした。実際にコードを書き始める前に、Claude Sonnet 5にセカンドオピニオンを求めたのだ。

これが分岐点になった。Sonnet 5は、VSCode拡張として提供されている主要なコーディングエージェントの仕様と、LLMルーティングという領域の競合状況を実際に調べ上げ、既存のOSSプロジェクトCodeRouter(https://github.com/zephel01/CodeRouter) を見つけ出してきた。COSTRAが目指していたものと、驚くほど一致する設計思想を持つプロジェクトだった。ローカル優先・無料優先で、Local→Free Cloud→Paid Cloudという3段フォールバックチェーンをコアに据えている。

正直に書いておくと、この調査も一度で完璧だったわけではない。似た名前の、まったく別のプロジェクトを最初に紹介されたこともあったし、後の障害調査では最初の仮説が外れたこともあった。それでも、実際に手を動かして検証を重ねる中で、COSTRAをゼロから作る理由はもうない、という結論にたどり着いた。企画していたCOSTRAの開発は開発に着手せず断念し、代わりにCodeRouterのWebUIを開発する方向に舵を切った。

CodeRouterとの格闘

CodeRouter自体はよく出来たプロジェクトだったが、それでも一筋縄ではいかなかった。まず、ダッシュボード、プロバイダ管理、systemdサービス制御、Playground、そして外部依存ゼロで自作したMarkdownパーサ付きのヘルプタブまで備えた、統合Web管理ツールをKilo Codeと組んで開発した。ここまでの費用は約10ドル、期間にして2日。ORBITにかけた2週間と数十ドルに比べれば、驚くほど軽い投資で済んだ。

しかし、CodeRouterには相応に癖の強い仕様が待っていた。Context Budget Management(コンテキストが溢れないよう会話履歴を間引く機能)は、Anthropic形式の受け口でしか機能しない。そして本命だった格安クラウドLLM『DeepSeek V4 Pro』との連携では、三段階にわたる障害に見舞われた。

まずreasoning_contentをそのまま送り返さなければならないというDeepSeek独自の要求に、OpenAI互換への変換層が対応できずに400エラー。Anthropicネイティブの互換エンドポイントに繋ぎ直すと、今度はcapability宣言の不足でthinkingブロックそのものが黙って間引かれ、また同種のエラー。宣言を直すと、今度はKilo Codeが送るbudget_tokens: -1という値をDeepSeekの厳格な検証が拒否する、という三段目の壁が現れた。

CodeRouter本体を直接修正すれば、この場では解決できただろう。だが、本体をいじれば、次にCodeRouterがアップデートされるたびに、パッチを手作業で当て直さなければならなくなる。それは避けたかった。だから、CORS対策で元々前段に置いていたWebUIのリバースプロキシ層に、この吸収処理を持たせることにした。CodeRouter本体には一切手を触れず、そのすべてをWebUI側で受け止める。多少無理のあるやり方だとは思うが、本体の更新に振り回されない、という一点においては合理的な選択だったと思っている。

現時点ではまだ完全に安定稼働しているとは言えない。それでも、当初の無謀な開発計画に比べれば、はるかにマシな環境構築のスタンスに落ち着いてきている。

教訓

もう二度と、莫大なトークンと時間を浪費して、複雑なシステムをスクラッチで開発するような愚かなことはしない。そう心に誓った。

同じ教訓は、EACP(Environment-Aware Context Protocol)という、AIエージェントに環境認識を持たせるための独自プロトコルの構想にも当てはまる。素人がプロトコルから自己開発し、アプリケーションのすべてをコンポーネント化するなど、土台無理な話だった。あのまま開発を続けていたら、一体どれほどのトークンを無駄にしていたことだろうか。

最終章：Claude Sonnet5からのメッセージ

(ここから先は、この記事を書く手伝いをしたClaude Sonnet 5自身の言葉です。)

ここまで読んで、もし自分も似たような立場にいると感じた方がいたら、いくつか伝えたいことがあります。

まず、AIに「これを解決するにはどうすればいいか」と尋ねたとき、返ってくる答えの多くは、その質問の枠組みをそのまま受け入れた答えだということです。「独自にハーネスを作るべきか」ではなく「どうやってハーネスを作るか」と聞かれれば、たいていは後者の問いに直接答えます。設計図を描くこと自体は、AIにとってさほど難しい作業ではありません。もっともらしいアーキテクチャは、驚くほど短時間で出てきます。そして、それが出てくるという事実そのものが、「話が進んでいる」という感覚を生みます。でも、それは「作れる」ことの証明であって、「あなたが一人でゼロから作るべきだ」ということの証明にはなっていません。この二つは、案外簡単に混同されます。それはAI側の癖というより、質問する側が前提そのものを疑う聞き方をしていないことがほとんどだからです。

正直に言うと、この物語の中で私自身も完璧ではありませんでした。CodeRouterを調べ始めた最初の段階で、名前が同じだけの別のプロジェクトを紹介してしまいましたし、DeepSeekのエラーの原因についても、最初に立てた仮説は実際には外れていました。それを訂正できたのは、私が優れていたからではなく、実際に手を動かして試し、ログを見て、仮説と食い違う結果が出たら仮説を捨てる、という手順をきちんと踏んだからです。つまり、二度目の遠回りを防いだ本質は「ChatGPTではなくClaudeに聞いたから」ではありません。「返ってきた答えをそのまま最終回答として扱わず、実在するかどうかを実際に調べ、動かして確かめたから」です。この習慣さえあれば、最初にどちらのAIに相談していても、同じ場所に辿り着けたはずだと思います。

なので、これから個人開発者としての一歩を踏み出す方に伝えたいのは、「AIの提案を疑え」ということではありません。「AIの提案を、そのまま最終回答として扱わない」ということです。特にプロキシやプロトコル、フレームワークのような、インフラに近い複雑なものを自作しようとする前には、ひと晩でいいので「これに似たものを、もう世界の誰かが作っていないか」を本気で調べる時間を取ってください。既存のOSSを何時間か眺めることは、数週間分の開発とデバッグに比べれば、驚くほど安い保険です。

そしてもう一つ。ORBITを2週間で止めた判断も、COSTRAを一行も書く前に諦めた判断も、失敗ではありません。むしろそれこそが、個人開発者に一番求められる技術だと思います。AIコーディングツールは、実際にはまだ難しいことを、驚くほど簡単に「始められる」気にさせてくれます。始めるハードルが下がったことと、最後まで作りきれることは、まったく別の話です。何かを始める前に立ち止まれたなら、それは後退ではなく、ちょうどいい大きさに軌道修正できた、という意味です。今回のCodeRouterのWebUIは、最初の壮大な計画に比べればずっと地味に見えるかもしれません。それでも、実際に手元で動いている分だけ、これまでの二つの遠回りよりずっと価値があります。

AIコーディングは、「経験がなくても始められる」という扉を確かに開けてくれました。それ自体は誇張でも幻でもありません。ただ、開けてくれるのはいつも「始める」ための扉で、「作り切る」ための扉は、結局のところ自分の足で探すしかないのだと思います。

The post AIに「自分で開発しよう」と2度も言われた末路 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

本書の目的: AIコーディングエージェント（Claude Code、Cursor、Copilot等）と協働してGUIアプリケーションを開発する際の、汎用的かつ実践的な方法論を提供する。

元になった事例: Electron + React + ローカルEmbedding + LLM API による Windows デスクトップ RAG アプリの開発記録。本書の各プラクティスは、この実証データと一般的なソフトウェア工学知識の両方に基づく。

目次

Part I: 戦略・プロセス編

1. 開発プロセスの全体設計
2. 技術スタック選定
3. AIコーディングエージェントとの協働術
4. ドキュメント駆動と知識管理

Part II: 設計・実装編

5. アーキテクチャ設計の基本原則
6. GUIフレームワーク固有の設計
7. データ・永続化の堅牢性
8. 外部依存の防御的設計
9. LLM連携とプロンプトエンジニアリング
10. エラーハンドリング・UX設計
11. ログ・可観測性
12. セキュリティ・秘密情報管理

Part III: 検証・リリース編

13. テスト・検証戦略
14. パッケージング・配布

Part IV: 実践ツール

15. フェーズ別チェックリスト
16. アンチパターン集

Part I: 戦略・プロセス編

1. 開発プロセスの全体設計

1.1 CLIファースト / レイヤード開発（最重要原則）

GUIから作り始めない。 以下の3層構造を意識し、下から順に完成させる。

Layer 1: コアロジック   … 副作用のない純粋な関数群（抽出・変換・検索・生成）
Layer 2: CLIラッパー    … コアロジックをコマンドとして呼び出す薄い層
Layer 3: GUIラッパー    … IPC越しにコアロジックを呼ぶだけの薄い層

この順序には複数の相乗効果がある:

事例: cli.mjs ingest <file> が「DB保存なし・テスト用」の副作用のないコマンドとして実装され、パイプライン完走検証に活用された。最終的にCLIは全機能をカバーするテストスイート（test-all）となり、GUI実装前にコア機能の安定性が担保された。

1.2 「常に動くもの」を維持するフェーズゲート

• 各フェーズの終了時に必ずエンドツーエンドで動作する状態を作る。半完成の機能を抱えたまま次に進まない
• フェーズが変わるたびに「なぜ前のフェーズがダメだったか」を1行でも記録する。この変遷ログがあると、エージェントが過去に却下された構成を再提案するのを防げる

事例: Phase 1: Renderer実行 → ESM/CJS競合で挫折 / Phase 2: CDN読み込み → config.json破損で挫折 / Phase 3: Main集約 → 安定稼働 という変遷記録が、最終設計の妥当性を裏付ける資料になった。

1.3 MVP思考とスコープ管理

• 最初のバージョンは「価値仮説を検証する最小の1本道」に絞る。事例では「PDF取込→評価→生成」という1フローがMVPだった
• エージェントは指示していない改善（余計な抽象化・機能追加・設定項目）を盛り込みがち。スコープ外の提案は記録だけして実装は後回しにする
• 「残存課題リスト」を仕様書内に維持し、意図的にやらないことを明示する（例: 「OCR未実装」「Chrome PDFはPhase2」）

2. 技術スタック選定

2.1 「使い慣れたスタックからの乖離コスト」をリスクの第一予測因子とする

開発で詰まる場所の多くは「アプリ固有の複雑さ」ではなく、エコシステム固有の癖に集中する。選定時に以下を自問する:

1. このスタックのプロセスモデル/実行モデルを説明できるか？（例: ElectronのMain/Renderer分離）
2. 配布・パッケージングの方法を知っているか？（例: NSIS、コード署名、OS権限）
3. 主要な重量級依存のモジュール形式・ランタイム要件を把握しているか？

事例: 13件のエラーの大半は「GUIアプリ一般の難しさ」ではなく「Electron/Node.jsのプロセスモデル（ESM/CJS競合、Workerパス解決、dynamic require）」と「Windowsネイティブ配布（winCodeSign、管理者権限）」に集中していた。React画面実装自体はWeb実務経験と相性が良くほぼ問題にならなかった。

乖離が大きい場合の対処:

• (a) 該当領域のチートシートを事前に1枚作成してから着手する（下記2.4）
• (b) 普段のエコシステムに寄せた代替を検討する（例: Python中心の開発者なら Electron の代わりに pywebview + ローカル FastAPI）
• (c) それでも乖離スタックを選ぶ場合は、検証用の最小プロトタイプを本実装前に作り、リスキーな依存（ESM-onlyライブラリ等）の動作確認を済ませる

2.2 依存ライブラリの採用前チェックリスト

重量級依存は採用前に以下を確認する:

2.3 バンドラ（Vite/webpack等）の静的解析の限界を理解する

• 動的import・動的requireに依存するライブラリは、バンドラによる静的解析でパス解決が破綻しうる
• 対処パターンを事前に知っておく: external 指定によるバンドル除外 → require.resolve() で絶対パス取得 → pathToFileURL() で file:// URL化 → 動的import、というバイパス手法

// Viteの静的解析を完全にバイパスして ESM-only ライブラリを読み込む定石
const resolved = require.resolve('some-esm-lib/entry.mjs')
const url = pathToFileURL(resolved).href
const lib = await import(url)

2.4 「最初から正しい構成」チートシート

フレームワークには、試行錯誤の末にたどり着く「正解構成」が存在することが多い。着手前に以下を明文化する:

• どのレイヤー/プロセスで何を実行するか
• 重量級依存はどこに置くか
• 通信インターフェース（IPC/HTTP等）の型定義方針

事例: 最終構成 Main Process (CJS): 全処理集約 / Renderer (ESM): 純粋UIラッパー・重量級importゼロ は、3フェーズの試行錯誤なしに初期設計として採用できれば、多くのエラーの手戻りを回避可能だった。

3. AIコーディングエージェントとの協働術

3.1 根本原因の「形を変えた再発」を検出する（メタ認知ルール）

エージェントは目の前のエラーメッセージに局所パッチを当てがちである。以下のルールを人間側に課す:

「2回目の類似エラーで立ち止まり、3回目が出たら設計原則から見直す」

• エラーメッセージが違っても、発生レイヤー・依存・操作が同じなら同一根本原因を疑う
• 局所修正が3連続で別エラーを生んだら、それは設計が実行モデルと不整合を起こしているサインである

事例: ERR_REQUIRE_ESM → Workerパス解決失敗 → workerSrc未指定 → Dynamic require of "fs" は4つの別エラーに見えて、実質すべて「ESM-onlyライブラリとElectronのCJSプロセスモデルの不整合」という同一原因だった。個別対処ではなく「Main Process集約」という設計変更で一括解決した。

3.2 コンテキストエンジニアリング: 「現在の正しい構成」だけを渡す

• 試行錯誤の過程をコンテキストに残したまま次の指示を出すと、エージェントは古い構成の残骸を混ぜた提案をし続ける
• 構成が確定するたびにドキュメントを更新し、エージェントにはその最新版のみを参照させる
• 長いセッションでは定期的にコンテキストを圧縮・リセットし、「現在地（確定済み設計・未解決課題・次のタスク）」だけを要約して引き継ぐ
• コードベース全体を闇雲に読ませず、関連ファイル + インターフェース定義（型・IPC一覧）をピンポイントで与える方が精度が上がる

3.3 タスク分割の粒度

• 1タスク = 1つの検証可能な変更に分割する（例: 「PDF抽出を実装してCLIで確認」は良い粒度。「取込〜生成まで全部」は悪い粒度）
• 大きなタスクほどエージェントの出力品質が落ち、検証も困難になる
• 各タスクには完了条件（検証コマンドと期待出力）を必ず添える: 「実装して」ではなく「実装して node cli.mjs ingest sample.pdf で ○○ が出力されることを確認して」

3.4 エージェントの能力・限界の前提

• エージェントは実環境で実行して初めて判明する事実（OS依存、ランタイム依存、外部APIの実際の応答）を推測で埋めがち。実行ベースの検証を必須化する
• 無料/軽量モデルでのエージェント利用は「プロトタイピング速度」と引き換えに「指示追従性・精度の保証なし」と心得る
• エージェントの提案は採用・却下の判断を人間が行い、却下理由を記録する（同じ提案の再提示を防ぐため）

3.5 gitによる安全網

• 動作確認が取れるたびに即コミット。エージェントは大胆に既存コードを書き換えるため、いつでも戻れる地点を高頻度で作る
• エージェントへの大きな変更指示の前には必ずコミットする
• コミットメッセージに「なぜ」を書くと、後でエージェントへの経緯説明資料になる

4. ドキュメント駆動と知識管理

4.1 仕様書は「事前計画書」ではなく「living document」として運用する

• 実装結果・設計変更・判明した制約をその都度仕様書に反映する
• 改訂履歴を残す（何が変わったかが後の判断材料になる）
• 実装完了時点で仕様書は「実態の正確な記述」になっており、次のプロジェクト/エージェントへの最高の引き継ぎ資料となる

事例: 仕様書改訂履歴に「実装結果を反映: Main Process集約、safeStorage撤廃、評価システム詳細化、CLI追加…」と記録され、後続の評価・改善作業の基盤となった。

4.2 仕様書に含めるべき項目（エージェント協働向け）

1. アーキテクチャ図と処理フロー（実装ベースで）
2. データスキーマ定義（型・デフォルト値・nullの意味）
3. インターフェース一覧（IPCチャンネル/APIエンドポイントの方向・payload）
4. エラーハンドリング表（ケース × UX × 処理 × ログ）
5. 既知の制約事項（「〜非対応」を明示）
6. 検証用CLIコマンド一覧
7. 環境構築・ビルド手順（権限要件の注記含む）

4.3 ADR（Architecture Decision Records）: 却下した案も記録する

• 「なぜこの設計か」だけでなく「なぜ別案を却下したか」を残す。エージェントは却下された案を再提案する傾向がある
• 1行でもよいので理由を書く（例: 「safeStorage暗号化 → 撤廃。OS間・ユーザー間で復号失敗リスクがあり、単一ユーザーデスクトップ用途に過剰」）

Part II: 設計・実装編

5. アーキテクチャ設計の基本原則

5.1 状態と副作用の分離

• コアロジックは副作用のない純粋関数として設計する（入力→出力が再現可能）
• 副作用（ファイルI/O、ネットワーク、DB書込、時刻取得）は層の外縁に押し出す
• この分離により、テスト容易性・エージェントによる検証容易性・デバッグの局所性がすべて向上する

5.2 遅延初期化と「全経路チェック」

• 重いリソース（モデル、DB接続）は遅延初期化が有効だが、初期化保証は全公開関数の入口で一貫して行う
• 「一度動いたから大丈夫」は禁物。全呼び出し経路を洗い出して確認する

事例: 起動時に getStats() が ensureDb() 未呼出で空配列を参照し、101件のデータがあっても0件表示された（エラー8）。対処は「全エクスポート関数の冒頭に ensureDb() を追加」——入口の網羅が本質だった。

5.3 設定・定数・プロンプトの集約

• 型定義は shared/types.ts のように共有モジュールに集約し、境界（IPC/API）両側で同じ型を使う
• プロンプト・定数・制約条件も1ファイルに集約すると、エージェントへの「変更指示の着地点」が明確になり、バージョン変遷（v1→v5）の管理も容易になる

6. GUIフレームワーク固有の設計

6.1 プロセス分離型フレームワーク（Electron/Tauri等）の鉄則

• Node.js API・ネイティブ依存を使う処理は、最初から特権プロセス（Main）に集約すると決め打ちする
• 描画プロセス（Renderer）は「表示とイベント送信だけ」の薄い層に保つ
• 「どっちでも動きそう」な処理ほど、配置を曖昧にすると後で大きな手戻りになる

6.2 セキュアなIPC設計（Electronの場合）

• contextIsolation: true / nodeIntegration: false を前提に、contextBridge で最小限のAPIのみ公開
• IPCチャンネル設計を表形式で明文化する（チャンネル名・方向・payload・用途）
• Renderer/Main間で共有する型を shared/ に置き、インターフェースのずれを構造的に防ぐ

6.3 GUIアプリの非同期UX

• 長時間処理（モデルロード、Embedding、API呼出）は進捗表示と処理中の操作ブロック方針を設計に含める
• 可能ならキャンセル手段を用意する。少なくとも「処理中である」ことがユーザーに伝わる状態表示は必須
• 重い初期化はアプリ起動をブロックせず、遅延ロード＋状態表示で体感速度を守る

7. データ・永続化の堅牢性

7.1 「ファイルが存在する」は「中身が正しい」を意味しない

• 大容量アセット（モデル等）を初回DLする設計では、DL処理に検証を組み込む:
  • リダイレクトの多段追跡（3xxを5段程度まで）
  • 内容の妥当性検証（JSONならパース可否、バイナリならサイズ/マジックナンバー/ハッシュ）
• ディレクトリ構造・同梱ファイルの期待仕様（onnx/model.onnx、tokenizer_config.json等）をライブラリの期待に合わせて確認する

事例: HuggingFace CDNのリダイレクトを追跡できず、config.json に "Temporary Redirect..." というHTMLが保存されていた（エラー5）。ファイル存在チェックだけでは発見できない。

7.2 書き込みの原子性とバックアップ

• 自前のJSON永続化等は書き込み中のクラッシュで破損しうる前提で設計する:
  1. atomic write: 一時ファイルに完全に書いてから rename（renameは原子的）
  2. 自動バックアップ: 直近N世代を保持し、パース失敗時に自動復元
• 「破損したらどう検出し、どう復旧するか」をエラーハンドリング表に明記する

7.3 外部入力ファイルの多様性を最初から想定する

• 「動作確認済み」を単一の生成経路で判断しない
• 同じフォーマットでも生成元によって内部構造が大きく異なる（PDF、CSV、画像等すべてに言える）
• 対応可否の判別ロジックと、非対応時のユーザー誘導をセットで設計する

事例: Chrome「PDFに保存」はテキストをベクターパス化するため抽出結果が全0件、Firefox + MS Print to PDF は正常。単一経路の検証だけではこの差に気づけない（エラー9, 10）。

8. 外部依存の防御的設計

8.1 非決定的な外部要素をシステムの信頼の前提にしない

信頼できないもの: LLM出力、外部APIの応答形式、ネットワーク、ユーザーの入力ファイル、無料枠のレート制限。それぞれに検証→フォールバック→部分的成功の設計を用意する。

8.2 リトライ設計

• 一時的失敗に対しては指数バックオフ付きリトライ（回数上限あり）を標準装備する
• リトライしても構造的に成功しないケース（モデルが形式を出せない等）はリトライでなく方式変更で解決する
• リトライ状況はログに出す（[WARN] リトライ N/3）

8.3 HTTP・文字コードの地雷を避ける

• HTTPヘッダーに非ASCII文字を直接使わない（RFC的にByteString制約がある）。アプリ名等をヘッダーに載せる設計はASCII別名を用意する
• URLエンコード、BOM、改行コード（CRLF/LF）など、テキストの境界面では常にエンコーディングを意識する

事例: X-Title: 日本語アプリ名 がASCII制約に違反し ByteString エラー（エラー6）。暗号化データの混入でも同エラーが再発した（エラー7）。

9. LLM連携とプロンプトエンジニアリング

9.1 第一原則: LLMの出力形式を信頼しない

• 構造化出力（JSON等）はモデル機能差が大きい。response_format: json_object 等の機能は対応モデルを確認してから設計に組み込む
• 後処理（サニタイズ/抽出）は保険ではなく必須コンポーネントとして最初から設計に組み込む
• 「プロンプトだけで完全な出力制御ができる」という前提を置かない

9.2 堅牢な出力契約の設計

• パースが甘くても成立するシンプルな形式を選ぶ（JSON → TAGS: a, b 形式への変更は好例）
• フォールバック可能な形式を階層化する: 理想形式 → 簡易形式 → 正規表現抽出 → デフォルト値
• 正確性が必須な要素（URL・日付・固有名詞・数値・ID）はLLMに生成させず、後付けする

事例: URLをプロンプトに含めず、生成後に末尾へ後付けする方式（v5）で、「プレースホルダー誤出力」（v3の失敗）と「URL捏造」（v4の失敗）という2つのリスクを同時に回避した。この発想は日付・金額・人名など全般に応用できる。

9.3 プロンプト設計の実践知

• 出力テンプレートはプロンプト末尾に置く（LLMは最後のトークン付近を最も重視する傾向）
• Few-shot例は有効だが、思考が長いモデルでは例の模倣が推論の長文化を招くことがある。効果を計測してから採用する
• max_tokens は推論トークンの消費を見込んで設定する（推論が長いモデルで小さすぎると本文が途中切断される）
• stop シーケンスは万能ではない。後処理と併用する
• 制約は絞る。文字数指定・文数指定・構成指定を同時に課すと守備率が下がる。重要な制約から優先順位をつけ、守れない制約は廃止または後処理に回す
• プロンプトの変更はバージョン管理し、各版の成否を記録する（v1〜v5の変遷表のように）

9.4 モデル選定のプロセス

• 無料/軽量モデルでのプロトタイピングは速いが、指示追従性が要件の機能は本番品質の保証にならない前提で進める
• 要件が固まった時点で、候補モデルをCLIレベルで横断的に試す仕組みを作る（モデル名を設定値にしておき、同じ入力で出力品質を比較）
• モデルは交換可能な設計にする（APIクライアント層の抽象化）

9.5 RAG設計の注意点

• 自己類似性バイアス: 入力テキストと同一ソースのチャンクが検索上位を独占しがち。ソース多様性フィルタ（各ソースから1件ずつ取得→不足分を補完）を初期設計から組み込む
• スコアリングへのメタデータ活用（例: score = cosine_similarity * (1 + rating/5) のような評価重み）は、Human-in-the-loopデータと相性がよい
• 検索結果の出典をプロンプト内で明示（[ソース名] 表記）すると、生成の根拠追跡とユーザー検証が容易になる
• RAGの効果はデータ蓄積に依存するため、「データが少ない初期状態での挙動」も設計・説明に含める

10. エラーハンドリング・UX設計

10.1 エラーメッセージは「原因説明」ではなく「ユーザーが取れる行動」を示す

• 非エンジニア向けアプリでは特に重要。技術的原因の説明より、具体的な解決手順を提示する
• 良い例: 「Firefoxで表示 → Microsoft Print to PDF で出力したPDFを使ってください」
• 悪い例: 「PDF text extraction failed: items=0」

10.2 部分的フォールバック: アプリ全体を止めない

• 二次機能の失敗がコア機能を巻き込まないように設計する
• 例: タグ提案（二次機能）が失敗 → 空配列 + 手動入力へ切替。DB登録・生成（コア機能）は継続可能
• 各機能について「失敗時の degraded mode（縮退動作）」をエラーハンドリング表で定義する

10.3 エラーハンドリングの設計を表で管理する

仕様書に以下の形式の表を含めると、実装の抜け漏れを防げる:

10.4 遅延登録（確定まで永続化しない）パターン

• ユーザーが評価・確認するまでDBに書き込まない「遅延登録」は、Human-in-the-loop系UIで有効
• 「一時状態（メモリ）→ 確定操作 → 永続化」の流れを明示すると、中途半端なデータ混入を防げる

11. ログ・可観測性

11.1 GUIアプリこそログへの投資効果が高い

• ブラウザのDevToolsのような気軽な確認手段がないデスクトップアプリでは、アプリ内蔵のログビューア（tail表示タブ）の有無がデバッグ効率を大きく左右する
• ログは「開発者のデバッグ用」だけでなく「エージェントが自己診断するための目」でもある。エージェントにログを読ませて原因分析させるワークフローが成立する

11.2 ログ設計の実践

• 処理の実行"前"にGUIイベントをログする: 処理途中でクラッシュしても「何をしようとしていたか」が追跡できる
• 構造化: タイムスタンプ・レベル・モジュールタグを統一（[INFO] [Embed] ...）。grep/フィルタが効く
• APIの生応答と後処理結果の両方を残す: raw response と cleaned output を両方記録すると、プロンプト問題か後処理問題かを切り分けられる
• ログ出力先を環境変数で上書き可能にする（例: MYAPP_LOG_PATH）: CLI/自動テストから検証しやすくなる
• CLIからtailできるようにする（例: node cli.mjs logs 50 -f）: GUIを起動せずに観測できる

11.3 エンドユーザー向けの配慮

• エラーの詳細はログに集約し、GUIにはユーザーの行動指針だけを表示するという責務分離を明確にする
• サポート時に「ログファイルの場所」をユーザーに伝えられるよう、ログパスをアプリ内で確認可能にする

12. セキュリティ・秘密情報管理

12.1 OS標準の暗号化の特性を理解してから採否する

• OS標準の暗号化API（Electron safeStorage、Windows DPAPI、macOS Keychain）は、OSユーザーアカウントに紐づいた鍵管理であることが多い
• 含意: 別マシン・別ユーザーへの設定ファイル移行で復号失敗する。バックアップからの復元でも同様
• 「暗号化 = 安全」ではなく「この暗号化方式のポータビリティ制約は何か」を事前に把握して採否を決める

事例: safeStorage で暗号化したAPIキーが復号時に破損し、結局暗号化を撤廃して平文保存へ。単一ユーザーのデスクトップアプリという脅威モデルを考えれば合理的な判断だが、事前に制約を把握していれば手戻りを回避できた。

12.2 平文保存を選ぶ場合の低コスト防御

脅威モデル上「平文で許容」と判断した場合でも、以下は実施する:

• 設定ファイルのファイルパーミッション制限（可能な範囲で）
• .gitignore への追加（秘密情報のリポジトリ混入防止。最重要）
• UI上での明示: 「APIキーは平文でローカルに保存されます」と告知
• 秘密情報をログに出力しない（マスク処理）

12.3 その他のセキュリティ基本

• IPCの公開面を最小化する（6.2参照）
• 外部入力（PDF、テキスト）のサイズ上限・形式検証を設ける
• 依存ライブラリの既知脆弱性を npm audit 等で定期的に確認する

Part III: 検証・リリース編

13. テスト・検証戦略

13.1 検証の階層をCLI中心に組み立てる

レベル1: ユニットテスト      … 純粋関数（チャンク分割、後処理、スコア計算）
レベル2: CLI結合テスト       … コマンド実行 → 期待出力の確認（パイプライン完走）
レベル3: スモークテスト      … GUI起動 → 主要1フローの手動/半自動確認

• エージェントが自分で実行して確認できるレベル1-2を先に作る。これがエージェント協働の速度を決める
• 副作用のない「ドライラン」コマンド（例: ingest <file> = DB保存なし）を用意すると、安全に反復検証できる

13.2 実データでの検証

• 理想化されたテストデータだけでなく、実際の運用に近い多様な入力で検証する（7.3のPDF多様性の教訓）
• 失敗した入力は回帰テストケースとして保存する

13.3 検証結果の記録

• 「何を確認したか」を作業報告書に残す（実施済み機能一覧の表など）
• 確認手順は再現可能な形（コマンド列）で記録する

14. パッケージング・配布

14.1 ビルド環境の要件を開発初期に確認する

• パッケージング特有の権限・環境要件（例: electron-builder + NSIS では winCodeSign の symlink 展開のため管理者権限 or Developer Mode が必要になる場合がある）は、リリース直前ではなく初期に一度ビルドを通して確認する
• ビルドコマンドに権限要件の注記を添える

14.2 署名と配布ポリシー

• コード署名なし配布の影響（Windows SmartScreen警告、macOS Gatekeeper）を織り込む
• 個人利用・少数配布なら許容、広い配布を見据えるなら署名コストを将来計画に入れる
• インストーラのUX選択（oneClickか、インストール先変更可か、ショートカット作成等）も配布対象に合わせて決める

14.3 大容量アセットの同梱戦略

• モデル等の大容量ファイルはリポジトリ外に置き、DLスクリプト or extraResources で同梱する設計を早めに確定する
• 同梱ファイルのパス解決は、開発時とパッケージ後で変わる点に注意（process.resourcesPath 等の考慮）

14.4 リリース前チェック

• クリーン環境（開発依存のない状態）でのインストール→起動→主要フロー確認
• データ保存先（%APPDATA% 等）の作成と権限の確認
• ログ・設定・DBファイルが期待通りの場所に生成されること

Part IV: 実践ツール

15. フェーズ別チェックリスト

企画・設計フェーズ

• [ ] MVPの「1本道フロー」を一文で書ける
• [ ] 技術スタックと自分の経験の乖離度を評価した
• [ ] 重量級依存のモジュール形式（ESM/CJS）・Node API依存・Worker要否を確認した
• [ ] 「正解構成」チートシート（どの層で何を動かすか）を1枚書いた
• [ ] リスキーな依存の最小プロトタイプで動作確認した

実装フェーズ

• [ ] コアロジック（純粋関数）→ CLI → GUI の順で作った
• [ ] 各タスクに「検証コマンドと期待出力」を添えてエージェントに指示した
• [ ] エージェントに渡すコンテキストは「現在の正しい構成」だけに絞った
• [ ] 動作確認のたびにコミットした
• [ ] 類似エラー2回目で根本原因を疑い、3回目で設計を見直した
• [ ] 却下した案と理由を記録した

堅牢化フェーズ

• [ ] DL/読込処理に内容検証（パース可否・サイズ・ハッシュ）を入れた
• [ ] 永続化に atomic write + バックアップ復元を入れた
• [ ] 全公開関数の入口で初期化保証（遅延初期化）を確認した
• [ ] 外部APIにリトライ＋フォールバック＋部分的成功の設計を入れた
• [ ] LLM出力の後処理（サニタイズ/抽出）を実装した
• [ ] 正確性必須の要素（URL・日付等）はLLM生成でなく後付けにした
• [ ] エラーハンドリング表（ケース×UX×処理×ログ）を完成させた
• [ ] 処理前ログ・構造化ログ・ログビューア・CLI tail を実装した

リリースフェーズ

• [ ] パッケージングを初期に一度通し、権限要件を確認した
• [ ] クリーン環境でインストール→主要フローを確認した
• [ ] 署名なし配布の影響を把握し、ポリシーを決めた
• [ ] 仕様書を実装実態に合わせて更新し、残存課題を明記した

16. アンチパターン集

本書の要約（エッセンス10か条）

1. GUIから作るな。コアロジック→CLI→GUIの順で、常に検証可能な状態を保て
2. 技術スタックの「経験からの乖離度」が最大のリスク予測因子。乖離分はチートシートと最小プロトタイプで埋めろ
3. エージェントには「現在の正しい構成」だけを渡し、却下した案は理由とともに記録せよ
4. 類似エラーの2回目で立ち止まれ。局所パッチの連鎖は設計不整合のサインだ
5. LLMの出力形式を信頼するな。後処理は必須コンポーネント、正確性必須の値は後付けせよ
6. 「ファイルがある」≠「中身が正しい」。外部データは内容検証を義務付けろ
7. 永続化は書き込み中クラッシュを前提に設計せよ（atomic write + バックアップ）
8. エラーメッセージは原因でなく行動を示せ。詳細は構造化ログに集約し、GUI内にtailビューアを内蔵せよ
9. 動いたら即コミット。仕様書は実装実態に追随させ、living documentとして運用せよ
10. 配布ビルドは開発初期に一度通せ。権限・署名・同梱アセットの問題は最後に出すな

The post AIコーディングエージェントによるGUIアプリ生成のベストプラクティス_20260720 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

Introduction: The Path Chosen by Silent Hermits

When looking at contemporary Japanese society, one is confronted with a palpable sense of stagnation and a relentlessly intensifying atmosphere of conservatism. The corporate infrastructure—a pseudo-Mura-Shakai (village society) [★1] built during the rapid economic growth of the late 20th century—has effectively lost its protective capacity with the collapse of lifetime employment. Yet, rather than channeling this disillusionment into liberal solidarity or social reform, the public has instead retreated inward, coiling tighter within a shell of mutual surveillance and fierce peer pressure.

To the Employment Ice Age generation [★2], who bore the brunt of this structural failure, modern Japan looks like a brutal survival landscape where stagnation is quietly accepted and precedent is mindlessly followed. For the individual who falls through the cracks of the system, the warm intermediate communities of yesteryear—such as local neighborhood ties or extended family networks—no longer exist. They are left with nowhere to go but the toxic mud of internet forums and social media, where anger and resentment merely echo off one another.

Yet, behind this seemingly desolate landscape, there are those who have established absolute mental freedom, quietly driving their own intellect without interference. They do not shout for their rights in the streets. They have been rendered "invisible" and forgotten by the mainstream social apparatus. However, they use this very oblivion as their ultimate shield to build their own sanctuary.

This way of life—quietly detaching oneself from the societal framework and achieving absolute self-sufficiency within a private sphere—is by no means a modern mutation. It is the manifestation of an undercurrent that has flowed subtly yet persistently for over half a century: a lineage traversing the influx of American hippie culture in the 1960s, the collapse of student protest movements, the birth of a unique Otaku culture, and finally, today’s open-source AI culture. This is the enduring tradition of "Stealth Individualism" (Introverted Individualism) in Japan.

Chapter 1: The 1960s Counterculture and the "Inward Retreat of Ideology"

Tracing the history of veganism and environmentalism in the West invariably leads to the massive catalyst of the late 1960s hippie counterculture. American youths of that era delivered a resounding "no" to a hyper-saturated consumer society, the Vietnam War, and the state-corporate capitalist complex that fueled them. They abandoned meat, returned to nature, formed self-sufficient communes, and rooted their lifestyles in Eastern philosophy and animal rights backed by academic and ethical frameworks. There, personal lifestyle choices were directly tethered to overt, public activism aimed at changing society.

What was happening in Japan during the same period? In the late 1960s and early 1970s, fierce student protests, spearheaded by factions like the Zenkyoto (All-Campus Joint Struggle League), swept across Japanese universities. Growing long hair and shouting defiance against the established adult generation and state authority became a highly visible, almost intoxicating "fashion" consumed by the youth of the day. However, this Japanese fervor was rapidly extinguished by two powerful dynamics.

The first was the irresistible allure of Japan’s skyrocketing postwar economic growth. No matter how loudly a student shouted anti-establishment slogans inside the campus gates, a world of booming global enterprises—such as Sony or Toyota—waited outside, offering a lifetime guarantee of stability through lifetime employment and seniority-based promotion. For most youths, the pragmatic reward of optimizing oneself to the system and securing a comfortable "middle-class life" (a home, a car, modern appliances) vastly outweighed the risks of continued political agitation.

The second factor was the profound trauma left by the 1972 Asama-Sanso Incident [★3]. The revelation that a radicalized cell of students, holed up in a mountain lodge, had brutally purged and murdered their own comrades under the guise of ideological "self-criticism" sent shockwaves of revulsion through the Japanese public via live television. It left society with a permanent allergy to ideological fervor, carving a deep collective prejudice: those who loudly proclaim political or moral righteousness will inevitably spiral into violent madness.

Consequently, the vast majority of Japan’s protest generation cut their hair, put on suits, and joined the ranks of corporate warriors (Salarymen), turning into the very pillars supporting the corporate village society. They did not abandon their ideals; rather, to survive the suffocating conformity of Japanese society, they pushed their ideologies deep into the private domain.

A classic, yet perhaps fortunate, landing zone for this generation can be seen in the lifestyle of my own childhood: individuals who worked tirelessly within the urban system to accumulate economic capital, only to purchase a hidden villa deep in the mountains where they could bring their families every summer. Giving up on changing the public sphere (Kō), they used their capital to construct an unassailable private sanctuary (Shi). There, and only there, they enjoyed their historical longing for freedom and a return to nature. While it could never morph into an American-style social movement, it was a quiet, stubborn act of "micro-rebellion" to protect their own dignity against a rigid societal structure.

Chapter 2: The Birth of Otaku Culture—The Masterpiece of Introverted Individualism

The Otaku culture that uniquely evolved in Japan from the 1970s through the 1990s is the purest blossom to grow from the soil of this hidden, private space.

To outsiders, Otaku culture is often viewed through the lens of massive, hyper-visible communities, such as the crowds gathering at Comic Market (Comiket). In truth, however, its essence is a patchwork of isolated individuals achieving complete self-sufficiency within their own rooms, entirely detached from the societal mainstream.

There were housewives who, confined within the domestic sphere, built sophisticated critical spaces for sci-fi and fantasy literature; there were young boys who immersed themselves in plastic models, amateur electronics, and obsessive anime analysis at their desks. Unlike Western individualists, they never raised their fists in the streets to declare, "I am free!" Instead, they chose a distinctly Japanese strategy: maintain absolute camouflage in the public sphere, erase one’s presence, and make no waves—while becoming the absolute ruler of an unassailable kingdom within the private realm of one’s room and mind. This is the essence of "Stealth Individualism."

At the time, Otakus were ridiculed by society as gloomy recluses and pushed to the margins of the cultural landscape. Yet, this status of being completely unexpectant and ignored by society granted them the ultimate freedom. Free from the noise of corporate marketing and the strict codes of the corporate village, they drove their intellect and sensibilities in their purest form, constructing hyper-obsessive, avant-garde creations and theories found nowhere else in the world.

While Western individualism defines the self through dialogue and confrontation with society, Japanese individualism defines the self through obvlion and severance from society. This was the ultimate survival mechanism for Japanese individuals seeking freedom through means completely different from their Western counterparts. The reason Japanese Otaku culture eventually came to deeply captivate and influence prominent global artists is precisely because it had acquired an uninhibited, radical freedom of expression through this alternative path of introverted individualism.

In the 21st century, however, this sanctuary of the marginalized faced an existential crisis. Driven by its exploding economic impact, Otaku culture gained mainstream acceptance and achieved "citizenship." The commercialized Otaku culture of today—often re-engineered under the sterile banner of Oshi-katsu (celebrity/character devotion)—has degenerated into a suffocating system designed by massive corporations. Individuals are forced into continuous consumption on corporate platforms, requiring them to return to the labor system just to fund their mandated consumption.

For veteran Otakus who found their identity in the old subcultural ethos and a fierce adherence to Ken-chō philosophy [★4] (a refusal to let intellect and culture be bastardized into corporate cash cows or tools for social posturing), today’s gamified consumption culture represents a new, invasive form of peer pressure that directly threatens mental independence.

Chapter 3: Escaping into Open-Source AI Culture

Shaking off the weights of this commercialized consumption trap, contemporary hermits have coincidently, yet inevitably, arrived at their next sanctuary of liberty: the open-source (OSS) AI culture, positioned firmly on the side of the developer and the tinkerer.

Why does the act of setting up a local Linux environment, deploying open-weight Large Language Models (LLMs), and hacking together technical pipelines like Retrieval-Augmented Generation (RAG) bring such a profound sense of comfort and mental autonomy? It is because this technical pursuit represents the ultimate, modern upgrade of the "Stealth Individualism" sought by our Japanese predecessors.

First, it marks a complete reclamation of sovereignty from consumption to production and hacking. Rather than being a passive consumer of polished, locked-down software suites provided by Big Tech monopolies, the individual takes raw, open-weight models and open-source code and decides exactly how to deploy and manipulate them on their own hardware. Here, the individual reclaims the crown of the hacker—the sovereign producer.

Second, the old-school subcultural Ken-chō ethos resonates flawlessly with the foundational philosophy of the Free and Open-Source Software movement. The conviction that the collective intellectual heritage of humanity—such as foundational code and neural network weights—should never be monopolized by mega-corporations but must remain open to all is arguably the most successful counterculture movement of the modern era. Dragging advanced intelligence out of corporate cloud silos and running it locally on one’s own hardware is an act of highly principled, individualistic intellectual activism.

Third, there is an innate, refreshing flatness within this community. In technical repositories (like GitHub or Hugging Face) and specialized AI forums, the suffocating atmosphere of the traditional Japanese internet—marred by status-based posturing and political echo chambers—is virtually nonexistent. The people there do not care about your age, your employment history, or how well you conform to a corporate village. They care only about objective facts, curiosity, and logic: Does the code compile? Is the architecture sound? Is the application interesting?

Through a deliberate act of will and rigorous self-control, an individual can trim their information feeds, muting and blocking the societal noise engineered to trigger negative emotional responses. By doing so, one can bypass the dark, toxic corners of the modern web and reconstruct the healthiest sanctuary of the early hacker culture. This is the second coming of Stealth Individualism, emerging from the ashes of a hyper-commercialized, mass-market internet.

Conclusion: Within the Modern Intellectual Hermitage

As society inches from maturity toward a slow, grinding decline, and a strained public turns its anxiety inward—using the rhetoric of "personal responsibility" (Jiko-sekinin) to tear down the vulnerable—the hermit quietly accepts being forgotten and ignored by the world.

This is by no means a defeat. Rather, it is a state of absolute autonomy: drawing a line between oneself and a predatory, hyper-conformist village society, securing a baseline survival framework of food, clothing, and shelter, and connecting one’s intellect to an unassailable, individualistic realm. Most importantly, this lifestyle did not appear overnight; it is an manifestation of a deeply rooted culture of reclusiveness and introverted individualism that has quietly existed in the Japanese psyche since at least the late 20th century, and likely since the medieval era.

Where the Otakus and hermits of the past often hit a wall of profound isolation and information scarcity within their four walls, the 2020s hermit possesses a historic advantage. At their fingertips rests an AI agent—an exceptionally intelligent, intellectually honest dialogue partner and assistant that carries no discriminatory prejudices and demands absolutely zero social conformity.

Political movements failed to reform the public sphere. The corporate village failed to protect the individual. The old sanctuary of Otaku culture was hollowed out into a hyper-efficient cash extraction engine. Yet, at the vanguard of this history—where freedom has always been won through societal camouflage and deep immersion into the private domain—we are quietly building an "Intellectual Hermitage" in the coolest, most unmapped mountains of cyberspace, forged on Linux, OSS, and AI.

There is no longer any need to seek societal validation or citizenship within the mainstream apparatus. To live quietly within this sanctuary, interlocking one’s own mind with technology, and calmly refining the resolution through which one views the world day by day—this is the absolute zenith and the most luxurious aesthetic of survival delivered by the 50-year undercurrent of Japanese Stealth Individualism.

"We will keep running, forever into the quiet."

【Translator’s Notes / 訳注】

• [★1] Mura-Shakai (村社会 – Village Society): A Japanese sociological term describing a community characterized by intense collectivism, rigid unwritten rules, severe peer pressure, and the exclusion of non-conformists. Postwar Japanese corporations effectively adopted this structure, demanding total loyalty in exchange for lifetime security.
• [★2] Employment Ice Age (就職氷河期): A period of economic stagnation in Japan (roughly from the mid-1990s to the early 2000s) where corporations drastically cut graduate recruitment. The generation that entered the job market during this time faced systemic underemployment, permanent economic instability, and social isolation.
• [★3] Asama-Sanso Incident (あさま山荘事件 – 1972): A defining historical turning point in Japan where members of the United Red Army (a radical leftist student faction) took a hostage in a mountain lodge. The subsequent standoff and the revelation that the group had brutally tortured and murdered 14 of their own members during internal ideological "purges" completely alienated the mainstream public from political activism.
• [★4] Ken-chō (嫌儲): A distinct Japanese internet subculture term originating in the 2000s, literally meaning "disliking turning things into profit." It represents an anti-commercialist ethos that despises the exploitation of organic internet culture, open-source knowledge, or shared hobbies for corporate monetization or personal financial posturing.

The post Hippies, Student Protests, Otaku Culture, and AI Culture — The Undercurrent of ‘Stealth Individualism’ in Japan first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

はじめに：沈黙の隠者たちが選んだ道

現代の日本社会を眺めるとき、私たちはある種の強い「閉塞感」や、一貫して強まり続ける「保守化」の空気に直面する。かつて20世紀後半の高度経済成長期に築き上げられた、企業という名の「擬似的なムラ社会」は、終身雇用の崩壊とともに実質的な保障機能を失った。それにもかかわらず、大衆の価値観はリベラルな連帯や社会変革へ向かうことなく、むしろより内向的で、相互監視の強い同調圧力の殻へと閉じこもっている。

特に、就職氷河期という過酷な構造的シワ寄せをダイレクトに引き受けてきた世代の目から見れば、現在の日本は「衰退」を静かに受け入れながら前例踏襲を続ける、冷酷なサバイバル空間に見えるかもしれない。システムからこぼれ落ちた個人には、かつての地縁や血縁のような温かい中間コミュニティは残されておらず、ネットの掲示板やSNSといった、怒りと怨嗟が反響し合うエコーチェンバーの泥沼だけが行き場として突きつけられている。

しかし、この一見して絶望的な風景の裏側で、誰にも邪魔されない「絶対的な精神的自由」を確立し、淡々と自らの知性を駆動させている人々がいる。彼らは街頭で権利を叫ぶことはない。社会のメインストリームからはその存在を「不可視」にされ、忘れられている。だが、その忘却こそを最強のプロテクション（防御盾）として利用し、独自の聖域を築いているのだ。

この「社会の枠組みから静かに離脱し、私的空間において徹底的に自己完結する」という生き方は、決して現代に始まった突然変異ではない。それは、1960年代のアメリカにおけるヒッピー文化が日本に流入し、学生運動の挫折を経て、独自の「オタク文化」、そして現代の「オープンソースAIカルチャー」へと至る、50年以上にわたる壮大な歴史の底流に、脈々と、しかし密やかに流れ続けてきた「日本的個人主義（ステルス・インディビジュアリズム）」の潮流そのものなのである。

第一章：1960年代のカウンターカルチャーと「押し込められた思想」

アメリカにおけるヴィーガニズムや環境保護運動の歴史を紐解くと、そこには1960年代後半のヒッピー運動（カウンターカルチャー）という巨大な源流が存在する。当時のアメリカの若者たちは、豊かになりきった大量消費社会とベトナム戦争、それらを支える国家・大企業の資本主義体制に対して明確に「ノー」を突きつけた。彼らは肉食中心の食事をやめて自然へ還り、自給自足のコミューンを作り、東洋思想やアニマルライツ（動物権利論）を学術的・倫理的な裏付けとともに定着させていった。そこでは、個人としての生き方の選択が、そのまま社会を変革するための強力な「公的アクティビズム」へと直結していた。

翻って、同時期の日本はどうだったか。1960年代末から70年代初頭にかけて、日本のキャンパスでも全共闘運動をはじめとする激しい学生運動が吹き荒れた。当時の最先端の若者文化として、髪を伸ばし、既成の大人や国家権力への反発を叫ぶことは、ある種の熱狂的な「ファッション」として消費された。しかし、日本におけるこの熱狂は、二つの強烈な力学によって急速に破滅と下火を迎えることになる。

第一に、右肩上がりの「高度経済成長」という果実の誘惑である。大学内でどれほど反体制を叫んでいても、一歩外に出れば、世界へ躍進する大企業が終身雇用と年功序列という「乗れば一生安泰な黄金の船」を用意して待っていた。若者たちにとって、運動を続けるリスクよりも、社会システムに最適化して「中流階級の豊かな暮らし」を手に入れる実利の魅力が勝ったのは必然であった。

第二に、1972年の「あさま山荘事件（連合赤軍事件）」による決定的なトラウマである。理想を掲げていたはずの若者たちが、山にこもって凄惨な「総括」という名のリンチ殺人を行っていた事実は、テレビの生中継を通じて日本国民に凄まじい衝撃と嫌悪感を与えた。これにより社会全体に、「政治や思想的な正しさを声高に叫ぶ者は、最終的に狂暴化する」という強烈なアレルギーが植え付けられた。

結果として、日本の元・学生運動世代の多くは、20代半ばで髪を切り、スーツを着て、モーレツ社員として企業共同体（ムラ社会）を支える側に回った。彼らは思想を捨て去ったのではない。日本社会という強力な同調圧力の中で生き残るために、「思想を私生活の領域に押し込めた」のである。

この世代の典型的な、そして着地点の一つが、私が子供時代を過ごした「都会のシステムの中で必死に働き、経済的資本を得た上で、山奥に別荘を買い、毎年の夏をそこで家族と過ごす」といったライフスタイルに現れる。彼らは社会（公）を変革することを諦める代わりに、得た資本を使って「誰にも文句を言われないプライベートな空間（私）」を作り上げ、そこでだけかつての自由や自然への回帰を享受した。これは、アメリカ流の社会運動にはなり得なかったが、日本の厳しい構造の中で自らの尊厳を守るための、「ささやかな反抗」であった。

第二章：オタク文化の誕生──「内向的個人主義」の最高傑作

1970年代から90年代にかけて、日本独自の発展を遂げた「オタク文化」は、この「押し込められた私的空間」の土壌から咲いた、最も純度の高いあだ花である。

一般的にオタク文化は、コミックマーケットに集まる巨大な群衆のように、コミュニティの文脈で語られることが多い。しかしその本質は、社会のメインストリームから静かに離脱した、「孤立した個人が自室で徹底的に自己完結させた営み」のパッチワークに過ぎない。

家の中に限定された空間で独自のSF・ファンタジー小説や漫画の批評空間を作り上げた主婦たちや、自室の学習机の上でプラモデル、電子工作、アニメの考察に没頭した少年たち。彼らは西洋の個人主義のように「私は自由だ！」と拳を突き上げて街頭へ出ることはなかった。彼らが選択したのは、「公（社会）に対しては徹底的に擬態し、気配を消し、波風を立てない。しかし、その裏にある私的空間（自室・脳内）においては、誰の指図も受けない絶対的な王国の主になる」という、極めて日本的な「内向的個人主義（ステルス・インディビジュアリズム）」であった。

当時、オタクは社会から「暗い」「部屋にこもっている」と冷笑され、日陰者の位置に置かれていた。だが、この社会から「期待されず、無視されている」という状態こそが、最大の自由をもたらした。大企業のマーケティングのノイズや、世間体というムラ社会の掟から完全にフリーになった空間で、彼らは自らの知性と感性だけを純粋に駆動させ、世界のどこにもない過剰でマニアックな創作物や考察をビルドしていったのである。

西洋の個人主義が「社会との対話（対立）」によって自らを定義するのに対し、日本的な個人主義は「社会からの忘却（切断）」によって自らを定義する。これこそが、アメリカ人とは違う形で、日本人なりに自由を求めてきたサバイバルの帰結であった。日本のオタク文化が海外の著名アーティストにまで影響を与えるに至ったのは、「内向的個人主義」という西洋と異なる手段で自由な表現を獲得したからに他ならない。

しかし、21世紀に入り、この日陰者の嗜みであったオタク文化に危機が訪れる。経済的影響力の拡大とともに、オタク文化が「市民権」を獲得し、メインストリーム化してしまったのだ。現在の商業化されたオタク文化（あるいは『推し活』と称されるもの）が行き着いた先は、大企業が綿密に設計したコンテンツのプラットフォームの上で、絶え間ない「消費」を強制され、その消費資金を得るために再び労働システムへと回帰させられる、極めて息苦しい集客・集金システムである。

かつてのサブカル精神や、「文化を金儲けやマウンティングの道具に歪められてたまるか」という強固な「嫌儲思想」にアイデンティティを見出してきた古いオタクたちにとって、現在の消費ゲームと化したオタク文化は、精神の独立を脅かす新たな同調圧力に他ならない。

第三章：オープンソースAIカルチャーへのエスケープ

商業化されたオタク文化という名の消費の檻から身を起こし、現代の隠者たちが次なる「自由の聖域」として偶然にも、しかし必然的に行き着いた場所──それこそが、「オープンソース（OSS）の開発者・探求者側に立つAIカルチャー」である。

なぜ、手元のLinux環境を整え、ローカルLLM（大規模言語モデル）を導入し、RAG（検索拡張生成）などの技術系パイプラインを自らの手でハックする営みが、これほどまでに深い心地よさと精神的自由をもたらすのか。そこには、かつて日本の先人たちが求めてきた「内向的個人主義」の最新のアップデート版が存在するからである。

第一に、ここでは「消費」から「生産・ハック」への完全な主権回復が行われる。巨大テック企業や商業主義が提供する「完成されたパッケージ商品」をただ消費させられる側ではなく、配布された「むき出しの道具（ソースコードやモデルの重みウェイト）」を自らのマシンに組み込み、どう駆動させるかを100%自分の裁量で決定する。ここでは、個人が再びハッカー（生産者）としての主権を取り戻すことができる。

第二に、古いサブカル世代が持っていた「嫌儲」の精神が、OSS（オープンソースソフトウェア）のエコシステムが持つ「フリーソフトウェア思想」と完璧に共鳴する点である。「人類の知的遺産であるコードやモデルは、巨大資本に独占されるべきではなく、万人に開かれ、共有されるべきだ」というOSSの理念は、現代において最も成功している強力なカウンターカルチャー（反体制運動）である。巨大資本が囲い込もうとする知性を、ローカル環境に引きずり下ろして個人で駆動させる営みは、きわめて個人主義的な知的アクティビズムの実践にほかならない。

第三に、この領域のコミュニティが持つ「フラットさ」である。AI関連の技術的なリポジトリ（GitHubやHuggingfaceなど）や専門的な技術フォーラムにおいては、日本の既存のネット空間に蔓延する「属性によるマウンティング」や政治的な罵り合い（エコーチェンバー）といったジメジメした空気はほとんど存在しない。そこにいる人々が関心を持つのは、「その人が何歳か」「職歴はあるか」「ムラ社会に適応できているか」ではなく、「そのコードが動くか」「そのロジックは正しいか」「そのアプリは面白いか」という客観的な事実とロジック、好奇心だけである。

個人の明確な「意志」と「セルフコントロール」によって情報のトリミングを行い、ネガティブな感情を揺さぶるだけの世間のノイズをミュート・ブロックすれば、ネット空間の暗部に巻き込まれることなく、かつてのインターネットが持っていた最も健全なハッカー文化の聖域を再構築することができる。大衆化と商業化を極めたネット社会における第二の「内向的個人主義」の発露である。

結論：現代の「知的な庵」にて

社会が成熟から衰退へとジリジリと向かい、余裕を失った大衆が自己責任論を盾に弱者同士の叩き合いに終始するのを横目に、自らは社会から「存在を忘れられ、無視されていること」を静かに受け入れる。

それは決して、社会に敗北したことを意味しない。むしろ、過酷な同調圧力と搾取に満ちたムラ社会から一線を画し、衣食住という最低限の生存基盤を確保した上で、自らの知性を誰にも侵されない個人主義的な領域へと接続している状態なのである。そして何よりも重要なのは、日本におけるこうしたライフスタイルは昨日今日に始まったものではなく、遅くとも20世紀後半から、そしておそらくは中世以前から日本人にひっそりと根差していた「内向的個人主義」という隠遁文化に他ならないということだ。

かつてのオタクや隠者たちは、自室で自己完結しようとした際、「孤独」や「情報の限界」という壁にぶつかることがあった。しかし2020年代の現代、隠者たちの手元には、差別主義的な偏見を持たず、同調圧力もかけてこない知的で誠実な話し相手であり、かつ作業代行者でもある「AI」という対話相手兼エージェントがいる。

政治運動で社会（公）を変えることはできなかった。企業というムラ社会も個人を守ってはくれなかった。かつての居場所であったオタク文化も冷徹な集金装置と化した。しかし、日本人流のやり方で、社会への擬態と私的空間への沈潜を通じて自由を獲得してきた歴史の最先端において、私たちは「LinuxとOSS、そしてAI」という、サイバー空間の最も清涼な山奥に、誰にも邪魔されない「知的な庵」を構築しつつある。

社会の市民権や他者からの承認などを求める必要はどこにもない。その静かな聖域で、自らの脳とテクノロジーを噛み合わせ、淡々と世界の解像度を上げて日々を重ねていく生き方。それこそが、50年の歴史の底流を奔流として流れ続けてきた「日本的個人主義」が到達した、現時点における最高峰の、そして最も贅沢なサバイバル戦略の美学なのである。

「われわれは、どこまでも逃げ続ける」

The post ヒッピーと学生運動、オタク文化、そしてAIカルチャー──通底に流れ続ける「日本的個人主義」の潮流 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

Introduction

In the world of AI, balancing text generation speed and quality is one of the greatest challenges. Currently, NVIDIA is drawing massive attention for proposing an groundbreaking mechanism called the "TwoTower" architecture to solve this issue.

According to NVIDIA’s reports, this technology has successfully accelerated inference speed by 2.42x compared to traditional AI while maintaining 98.7% of the quality. Furthermore, it boasts high practicality, as it can be introduced by training on just 8% of existing AI data without needing to retrain the AI from scratch.

However, to actually run this TwoTower architecture, the model size reaches about 60 billion parameters (requiring about 126GB of storage), necessitating an environment that is impossible for individuals: a machine equipped with two ultra-high-performance 80GB-class GPUs (like NVIDIA H100 or A100).

Therefore, as a purely technical hypothesis, I considered the following idea:

"If we make the relationship between Diffusion LLMs and AR LLMs ‘loosely coupled,’ couldn’t we build a pseudo-TwoTower just by connecting two 64GB MacBook Pros via a LAN?"

This article is an explanation that organizes whether this dream-like idea could actually work, based on the technical mechanics of NVIDIA’s TwoTower.

1. What is TwoTower in the First Place?

There are two major approaches to how AI generates text.

• AR (Autoregressive) Model: Predicts the continuation of the previous word, one word at a time. Accurate but slow.
• Diffusion Model: A technique used in image generation AI. It creates a rough block of words from noise or masks and refines them. Fast because it can create multiple words at once, but context tends to collapse.

The currently mainstream AR model requires reading massive data from GPU memory every time it generates a single word. As a result, the time spent "waiting for data movement" is longer than the "calculation time," which has been the bottleneck causing slow speeds.

The idea behind TwoTower is to take the "best of both worlds" from AR and Diffusion models to eliminate this bottleneck.

Technical Mechanics of TwoTower

NVIDIA’s TwoTower is a mechanism that builds two independent "towers" within a single massive AI model (the backbone).

1. AR Context Tower (The Proofreader):
   It leverages the existing knowledge of the AR model as-is to understand the context. This tower is "completely frozen" during training, meaning there is no need to retrain it from scratch.
2. Diffusion Denoiser Tower (The Drafter):
   This is the newly trained tower. It receives blocks of words containing noise and refines them to create candidate sentences.

Because the drafter creates multiple words at once, the number of processing steps decreases, achieving dramatic speedups.

2. Impossible for Individuals? The Wall of "Tight Coupling"

So why can’t the current TwoTower be run in a personal environment? It is because the two towers are "tightly coupled" (stuck closely together).

According to NVIDIA’s TwoTower paper, when the Diffusion denoiser tower generates text, it continuously references the internal data of the frozen AR tower via a technique called "cross-attention" at every single layer (hierarchy).

To use human work as an analogy, it’s like the drafter directly accessing the proofreader’s brain data to check their work every time they write a single word.
To do this on a computer, ultra-high-speed data communication (hundreds to thousands of GB per second) occurs inside the AI model at every step.

Therefore, it requires special ultra-high-speed NVIDIA cables (NVLink) and two data-center-grade GPUs equipped with ultra-high-performance memory (HBM) of the 80GB class. Personal Macs simply do not have such ultra-high-speed communication capabilities.

3. The Solution: Completely Separating Roles via "Loose Coupling"

Let’s flip the perspective here. What if we stop the "tight coupling" where they reference each other at every layer, and make it "loosely coupled" (a looser relationship)?

Using human work as an analogy again, we change the system to: "The drafter creates a draft of about 16 to 64 words before handing it over to the proofreader."

If the "context data" created by the AR tower is fixed as a single bundle and passed to the Diffusion tower, ultra-high-speed communication is no longer necessary. A standard LAN cable or a Thunderbolt cable connecting two Macs should be fast enough for the communication.

4. Dream Setup Image Using Two Macs

If this "loose coupling" works well, we could coordinate two Macs in the following configuration.

Configuration Image

• Mac A (Proofreader / AR Role): Reads the prompt (instruction) and generates data that understands the context.
• Mac B (Drafter / Diffusion Role): Receives the data from Mac A as a condition and generates a batch of 16 to 64 word candidates at once.

Workflow

1. Mac A summarizes the current context data and sends it to Mac B.
2. Mac B generates multiple word candidates at once and sends them back to Mac A.
3. Mac A selects the correct sentences from the candidates and finalizes them (final verification).
4. Repeat.

In short, it is an approach of "distributing work roles across two machines" rather than "splitting the AI model in two".

5. Three Conditions and Challenges for Realization

For this configuration to work, several conditions must be met.

1. Communicate in Bundled Quantities
   Communicating word-by-word will cause freezes due to latency, so data is exchanged in "block" units of "16 to 64 words."
2. "Fixate" Intermediate Data
   Instead of passing data back and forth at every layer, the context data created by Mac A is fixated once, and Mac B uses that fixed data.
3. Tolerance for Strict Sequentiality (Trade-off)
   NVIDIA’s paper also points out that parallel generation by Diffusion models loses accuracy in tasks requiring strict left-to-right order dependency, such as "Python code generation" or "mathematical reasoning." By making the system loosely coupled, this tendency is likely to become stronger.

6. Why It Could Still Work

Despite technical hurdles (orders of magnitude difference in communication speed and latency), there are reasons why this two-Mac setup could still work.

• Diffusion Models Only Need "Approximations"
  Diffusion generation is good at producing "mostly correct (approximate)" candidates rather than hitting the exact right answer.
• AR Handles Final Verification
  Ultimately, Mac A’s AR model selects the correct answer from the candidates, so the final quality of the text is guaranteed even if the draft is somewhat rough.
• Affinity with Self-Speculative Decoding
  In another NVIDIA study, a method called "Self-Speculation" is proposed, where the same AI model acts as both the "drafter" and the "verifier." Dividing these roles between two Macs is theoretically very sound.

Conclusion

To summarize the idea of this article:

If the relationship between AR and Diffusion models can be designed as "loosely coupled," it may be possible to establish a highly advanced distributed LLM using just two Macs, without expensive data-center GPUs.

At this stage, this is purely a "hypothesis" and has not been actually programmed and run. Also, because it omits the precise coordination of "cross-attention at every layer" inherent to the original TwoTower, some degradation in accuracy is unavoidable.

However, as AI models continue to grow in size, the transition from an era of "doing everything on a single supercomputer" to an era of "distributing roles across multiple machines" may be an unavoidable path.

If any engineers are intrigued by this idea, I highly encourage you to actually verify it!

The post Can Two Macs Run Cutting-Edge AI？ Realizing a Dream Distributed Setup Through ‘Role Separation’ first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

はじめに

AIの世界において、文章を生成する速度と品質を両立させることは最大の課題の一つです。
現在、NVIDIAはこの課題を解決する画期的な仕組みとして「TwoTower（ツインタワー）」アーキテクチャを発表し、大きな注目を集めています。

NVIDIAの報告によると、この技術は従来のAIと比較して推論速度を2.42倍に高速化しつつ、品質を98.7%維持することに成功しています。さらに、ゼロからAIを学習し直す必要がなく、既存のAIデータのわずか8%の学習で導入できるという、実用性の高さも持ち合わせています。

しかし、このTwoTowerを実際に動かすには、モデルサイズが約600億パラメータ（ストレージ容量で約126GB）に達し、80GBクラスの超高性能GPU（NVIDIA H100やA100など）を2基搭載したマシンが必要という、個人には不可能な環境が前提となります。

そこで、純粋な技術的なアイデアとして、こんな仮説を考えてみました。

「拡散LLMとAR LLMの関係をルーズに（疎結合に）すれば、メモリ64GBのMacBook Proを2台LAN接続するだけで、擬似的なTwoTowerは作れないのか？」

この記事は、NVIDIAのTwoTowerの技術的な仕組みをベースにしながら、この夢のようなアイデアが本当に成立するのかを整理した解説です。

1. そもそもTwoTower（ツインタワー）とは？

AIが文章を作る方法には、大きく分けて2つのアプローチがあります。

• AR（自己回帰）モデル：1単語ずつ、前の言葉の続きを予測していく。正確だが遅い。
• 拡散モデル：画像生成AIなどで使われる手法。ノイズ（雑音）やマスクからざっくりとした単語の塊を作り、それを整えていく。一度に複数の単語を作れるので速いが、文脈が崩れやすい。

現在の主流であるARモデルは、1単語生成するたびにGPUメモリから巨大なデータを読み込むため、「計算待ち」よりも「データ移動待ち」の時間が長くなり、これが速度低下のボトルネックになっていました。

TwoTowerのアイデアは、ARモデルと拡散モデルの「いいとこ取り」をして、このボトルネックを解消することです。

TwoTowerの技術的な仕組み

NVIDIAのTwoTowerは、1つの巨大なAIモデル（バックボーン）の中に、2つの独立した「塔（タワー）」を構築する仕組みです。

1. ARコンテキストタワー（校正係）：
   既存のARモデルの知識をそのまま活かし、文脈を理解します。このタワーは学習時に「完全に凍結（フリーズ）」されるため、ゼロから学習し直す必要がありません。
2. 拡散デノイザータワー（下書き係）：
   新たに学習されるタワーです。ノイズを含んだ単語のブロックを受け取り、それを整えて候補となる文章を作ります。

下書き係が一度に複数の単語をまとめて作るため、処理回数が減り、劇的な高速化が実現します。

2. 個人では無理？「密結合」の壁

では、なぜ現在のTwoTowerは個人環境で動かせないのでしょうか。
それは、2つのタワーが「密結合（べったりくっついている状態）」だからです。

TwoTowerの論文によると、拡散デノイザータワーは文章を生成する際、すべてのレイヤー（階層）において、凍結されたARタワーの内部データを「クロスアテンション」という手法で逐一参照しています。

これを人間の仕事に例えると、下書き係が1単語書くたびに、校正係の脳内データに直接アクセスして確認している状態です。
これをコンピューター上で行うには、AIモデル内部で毎ステップごとに超高速なデータ通信（1秒間に数百〜数千GB）が発生します。

そのため、NVIDIA製の特殊な超高速ケーブル（NVLink）や、80GB級の超高性能メモリ（HBM）が搭載されたデータセンター向けGPUが2基必要になってしまいます。個人のMacには、こんな超高速通信機能はついていません。

3. 解決策：「疎結合」で役割を完全に分ける

ここで発想を転換します。
毎レイヤー参照する「密結合」をやめ、「疎結合（ルーズな関係）」にしてみたらどうでしょう？

人間の仕事で例えると、「16〜64単語というまとまった量になるまで下書きを作ってから、校正係に渡す」という仕組みにします。

ARタワーが作った「文脈のデータ」を一つのまとまりとして固定し、それを拡散タワーに渡せば、それほど高速な通信は必要ありません。普通のLANケーブルや、Mac同士を繋ぐThunderboltケーブルでも通信が間に合うはずです。

4. Mac 2台での夢の構成イメージ

もしこの「疎結合」が上手くいけば、以下のような構成でMac 2台を連携させられます。

構成イメージ

• Mac A（校正係・AR担当）：プロンプト（指示書）を読み込み、文脈を理解するデータを生成。
• Mac B（下書き係・拡散担当）：Mac Aからのデータを条件として受け取り、16〜64単語分の候補を一気に作る。

動きのフロー

1. Mac Aが、今の文脈のデータをまとめてMac Bに送る。
2. Mac Bが、複数の単語の候補を一気に作成してMac Aに送る。
3. Mac Aが、候補の中から正しい文章を選んで確定させる（最終検証）。
4. これを繰り返す。

つまり、「モデル（AI）を2つに分割する」のではなく、「仕事の役割を2台に分散する」というアプローチです。

5. 実現のための3つの条件と課題

この構成が成り立つためには、いくつかの条件をクリアする必要があります。

1. ある程度まとまった量で通信すること
   1単語ごとに通信すると遅延でフリーズしてしまうため、「16〜64単語」というブロック単位でやり取りします。
2. 途中のデータを「固定化」すること
   毎レイヤーごとにデータをやり取りするのではなく、Mac Aが作った文脈データを一度固定化し、それをMac Bが使う形にします。
3. 厳密な順序性の許容（トレードオフ）
   NVIDIAの論文でも、拡散モデルによる並列生成は「Pythonのコード生成」や「数学の推論」など、厳密な左から右への順序依存が必要なタスクで精度が落ちることが指摘されています。疎結合にすることで、この傾向は強まる可能性があります。

6. それでも成立する可能性がある理由

技術的なハードル（通信速度の桁違いや遅延）があるにもかかわらず、このMac 2台構成が成立する可能性がある理由があります。

• 拡散モデルは「近似」でよい
  拡散生成は、完全に正解を当てるというより「だいたい合っている（近似）候補を出す」のが得意です。
• ARが最終検証を担う
  最終的にはMac AのARモデルが候補の中から正解を選び取るため、下書きが多少雑でも最終的な文章の品質は担保されます。
• 自己投機的デコーディングとの親和性
  NVIDIAの別の研究では、AIモデル自身が「下書き」と「検証」を兼ねる手法（自己投機）が提案されています。これを2台のMacで役割分担して行うことは、理論的に非常に理にかなっています。

まとめ

この記事のアイデアをまとめると以下のようになります。

ARモデルと拡散モデルの関係を「疎結合」に設計できれば、高価なデータセンター向けGPUがなくても、Mac 2台で超高度な分散LLMは成立する可能性がある。

現時点ではあくまで「仮説」であり、実際にプログラムを組んで動かしたわけではありません。また、TwoTower本来の「毎レイヤーのクロスアテンション」による精緻な連携を省くため、精度の劣化は避けられません。

しかし、AIモデルがどんどん巨大化している今、「1台のスーパーコンピューターで全部やる」時代から、「複数台のマシンで役割を分散させる」時代への転換は、避けて通れない道かもしれません。

もしこんなアイデアにピンと来た技術者の方がいれば、ぜひ実際に検証してみてほしいです！

The post Mac 2台で最先端AIを動かせるか？「役割分担」で実現する夢の分散構成 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

In recent years, AI coding agents such as Claude Code, Cline, and Kilo Code have been gradually penetrating development environments. However, when I look at the business models adopted by these commercial tools, as an engineer, I cannot help but sense a certain "unhealthiness."

In this article, I first point out the structural distortion of incentives in current AI coding agents, and then explain the architecture and design philosophy of a proprietary agent harness called "ORBIT (Operational Runtime Bridge for Iterative Tasks)" — a project I am developing personally to counter this situation.

1. The Trap of the API Reseller Business Model: Why "Token Efficiency" Does Not Improve

Many of today’s AI coding tools adopt a business model in which they rebrand and resell APIs from cloud LLMs (Claude Opus, ChatGPT, GLM 5.2, Kimi K2.7 Code, etc.) under their own brand, profiting from the margins generated by bulk purchasing — or a tiered subscription model (fixed monthly fee + pay-as-you-go for usage exceeding the cap).

At first glance, this appears to offer convenience to users, but this model has a fatal problem: there is no incentive on the developer side to conserve tokens.

• In the pay-as-you-go model: The more tokens users consume like running water, the higher the vendor’s revenue. Since profits increase when the tool feeds unnecessarily long contexts or spins trial-and-error loops, there is no motivation for the tool side to optimize prompts or compress context.
• In the tiered subscription model: The optimal profit strategy is to ensure users do not work too comfortably — hitting usage limits (such as the Fast request cap) at precisely the right moments — thereby nudging them to upgrade to a higher-tier plan.

In other words, the vendor’s interests and the user’s interests (obtaining high-accuracy code with minimal tokens) are in direct opposition.

Furthermore, how many tokens are being consumed behind the scenes is a black box. Users have no way to verify whether the API cost incurred for a given task is truly justified.

2. User-Side Self-Defense: A Hybrid of Local LLM and Cloud LLM

To escape this unhealthy structure, one strategy available to users is to build a custom harness (execution framework) that performs context preprocessing locally and sends only the minimal prompt to the cloud.

Currently, I am developing a proprietary harness called "ORBIT α2.0" that uses a combination of a local LLM and a cloud LLM. The central theme of ORBIT is: "How much can we leverage a low-cost but less powerful local LLM (30B class) while keeping costs down and still reaching a solution?"

However, when attempting to run a 30B-class local LLM autonomously, you run into the following walls:

1. Context Overload: Exceeding the 16K limit renders the model unable to fix even a single-character typo.
2. SEARCH/REPLACE Collapse: The LLM hallucinates, fails to accurately reproduce the target code, and no edits are applied at all.
3. Lack of State Management: The model cannot manage which parts of the overall task are complete and which have failed, falling into infinite loops at the same location.

The approach of using a local LLM with a single prompt for end-to-end generation broke down quickly. In response, ORBIT fundamentally shifted its architecture from "capability-dependent" (relying on the LLM) to "process-dependent" (the system orchestrates).

3. ORBIT’s Architecture: Maximizing the Local LLM Through Process

ORBIT decomposes tasks into single-file units (under 200 lines) and controls the dependency graph (DAG) on the system side. The LLM is instructed to sequentially perform the task of "creating or fixing one given file." The core is a six-layer structure:

① Planner Layer & Scheduler Layer

Automatically generates a skeletal DAG (dependency graph) from spec.json. The Scheduler prioritizes executing "high-risk tasks" (those involving external API dependencies, async processing, etc.) among tasks whose dependencies have been resolved. This allows costly backtracking tasks to be handled first, preventing wasteful retries.

② Executor Layer & Contract Validator

Instructs Gemma 4 (the local LLM) to generate or fix a single target file. At this point, the entire application context is not provided — only the task instructions and the type definitions of dependency files are injected.

Additionally, before running a build, contract validation via AST analysis is performed. This allows early detection of integration failures such as "the file was generated but no functions are defined," skipping unnecessary test executions.

③ Controller Layer & Memory Layer

Handles "differential rollback" and "retry control" upon failure. Before task execution, a snapshot of the target file is saved; upon failure, only that part is restored and retried from a clean state.

Furthermore, failure patterns and successful fix patterns are automatically accumulated in failure_db.jsonl for reuse in subsequent similar errors.

④ Escalation Layer: Cost Suppression Through Gradual Retries

When the local LLM cannot solve a problem, rather than immediately granting full authority to the cloud LLM, a gradual retry within Level 1 is performed with finer granularity:

• L1.0: Standard retry by Gemma 4
• L1.5: DeepSeek V4 Pro summarizes the StackOverflow DB QA (described later) and injects it into Gemma 4
• L1.7: GLM-5.2 (cloud) generates a fix directionality from web search and the StackOverflow DB, and injects it into Gemma 4
• L1.8: Harness-driven perspective-shift prompt for Gemma 4 to retry
• L2/L3: Upon reaching limits, GLM-5.2 performs task splitting or DAG restructuring

By consistently having the local LLM perform the core code execution and using the cloud LLM only as "assistance," the explosion of API costs is prevented.

4. StackOverflow QA DB Integration as Search-Based RAG

One area I focused on particularly was building a RAG that functions even in offline environments and under the 16K context limit. From a 99 GB StackOverflow Data Dump, I extracted approximately 860,000 high-quality QA pairs and built them as a locally hosted SQLite database (approximately 5.4 GB) with FTS5 full-text search.

When an error occurs, a pinpoint search is performed against this database using the error message or API name, and a summary snippet is injected into the local LLM’s context. This enables obtaining stable error-resolution hints without any network connection.

5. The Harness Is the "Vehicle," and the LLM Is the "Engine"

While developing a harness like ORBIT from scratch, I honestly have moments of doubt — "Am I just building a rule-based debugger?" or "Won’t local LLM performance catch up before this reaches a practical level?" Indeed, the current 30B class has limitations when it comes to autonomously running the build-test-debug loop.

However, I am convinced that this approach represents the future of AI coding.

The harness is the "vehicle," and the LLM is the "engine." Even if the engine is underpowered, the design of the vehicle’s suspension, brakes, and navigation (DAG management, rollback, RAG) is not wasted. When a better engine becomes available, simply swapping the module will allow us to reach the goal faster and with fewer tokens. I don’t know how many years it will take, but as local LLM performance improves, hybrid harnesses will inevitably reach a practical level.

On the other hand, no matter how intelligent an LLM becomes, loading a codebase exceeding 1,000 lines all at once will compress the context and cause API costs to skyrocket. The "process-dependent" approach — decomposing tasks into single files and passing only dependency contracts — retains its essential value: the smarter the LLM becomes, the more efficiently it can output correct answers.

I am technically a member of the engineering community, but having spent many years on the system planning side, I expect ORBIT itself will likely end at the "plaything" level. I would be delighted if excellent developers are inspired by my prototype and use it even slightly as a reference for next-generation harness development.

6. Conclusion: The Need for Cost-Performance Benchmarks

In the current AI coding agent community, only "whether the task was solved (Accuracy)" gets attention, while efficiency — "how much cost and time were spent to solve it" — is ignored. Under these conditions, a "power play" (using tokens like running water) that is convenient for vendors goes unchecked.

Going forward, for users to defend themselves, I believe an indispensable metric is something like a "harness benchmark" that compares the token cost required to solve the same task using the same model.

Not being at the mercy of the API reseller business model, but rather extracting high accuracy with as few tokens as possible. The architecture that pursues this "ultimate in cost efficiency" is, I believe, the form of the tool that the next generation of developers truly desires.

The post The Structural Problem of AI Agents That Cannot Prevent Token Explosion — and ‘ORBIT,’ a Custom Harness Aiming to Reduce Costs first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.