人工知能（AI）との開発における「おとぎ話の弟子」問題を回避した経験記述

カーソン・グロス氏は、2026 年 6 月 29 日の記事において、AI に対する両面性の姿勢を説いています。過去 1 年で強力なツールとして定着した一方、個人の知能鈍化や社会的なリスク（環境問題など）も伴うと警告しています。

本稿では、ハイパースクリプト（Hyperscript）という独自言語のパースャー（パーサー）開発において遭遇した退行現象（バグ）の調査・解決過程を通じて、AI と開発者がどのように連携し、かつどこで注意すべきかを示します。

問題の背景：ハイパースクリプトのパースャー

言語の特性:
- ウェブ用として設計された代替的なインタープリテッドスクリプト言語です。
- 皮肉なことに、その実装自体はJavaScriptで書かれています。
意図的な非標準化:
- パースの規則を意図的に破ることを目指しました。
- 主な特徴（例）：
  - 解析ロジックが要素内に配置されている（Localed）。
  - パサーがプラグ可能で、文法は動的に定義される。
  - プロパティアクセスには複数の構文をサポート。
- 「猫を皮むく方法は複数ある」ことの証明であり、プロジェクト内で良好な機能を提供しています。

バグ報告：0.9.91 リリース時の退行現象

アップグレード時に以下のコード式が正しく解析されなくなりました：

fetch `{% url 'trade:get_symbol_data' %}?symbol=${symbol}` as JSON

発生した誤作動

文字列リテラルをJSON に変換してから Fetch 関数に渡そうとしました。
ユーザーが期待した挙動（指定された URL を Fetch し、結果をそのまま扱う）とは逆の振る舞いでした。

問題の原因分析

根本原因:
```
go
```
コマンド用の共通メソッド
```
parseURLOrExpression()
```
を抽出・共有する際のリファクタリングが過度だったためです。
「as」キーワードの二重性:
- 式の意味: 変換表現を示す（例：
```
set x to "42" as Int
```
  ）。
- 修飾子の意味: Fetch コマンドのレスポンス変換方法を指示する（例：
```
fetch url as Text
```
  ）。
競合:
- リファクタリングにより、
```
fetch
```
  後の式をパースする際に「as」を表現として消費しきってしまい、Fetch 用の修飾子として機能できなくなっていました。
- これは AI を使って数分で特定できました（自独理解ではさらに時間がかかったでしょう）。

問題解決のプロセス：AI との相互作用と判断

AI は原因発見に優れていましたが、純粋な解決案の提示には弱みがありました。人間がアーキテクチャを深く理解した上で AI と協調して解決しました。

提案された修正案 1：ハック的な試み ❌

アプローチ: 「文字列のような」リーフをまずパースし、失敗すれば式へとフォールバックする手法。

return this.parseElement("stringLike") || this.requireElement("expression");

結果: 報告された直後のケースでは機能しましたが、汎用性が不足していました（変数をターゲットにする場合などでエラー）。
判断: **「あまりにもハック的であり、一般性が不足している」**として却下しました。

提案された修正案 2：より良いが不要な複雑さ ⚠️

アプローチ: パサーに

noConversions

フラグを追加し、特定条件下で処理を中止させる仕組みを作る。

// AsExpression.parse()
if (parser.noConversions) return;

欠点: 「コンテキスト感知型」なパースロジックを意図せず追加することになり、既存の複雑なアーキテクチャと重複します。
判断: 冗長であるとして却下しました。

ハイパースクリプトのパースにおける「追従（Follow）」の活用 ✅

仕組み:
- パサーには「follows」という概念があり、上位要素で要求されたトークンを意味します。
- 「when」機能のように、宣言内で「or」を論理接続詞ではなく分離子として使うなど、奇妙な再帰降下パースを実現しています。
活用方法:
- 新たなフラグを追加するのではなく、「as」をフォロー（Follow）として押し込みます。
- 式をパースした後、「as」を再びポップします。
- これにより、「AsExpression」が不必要にパースを試みるのを防ぎ、変数などの一般ケースも正常動作させます。

提案された修正案 3：近いが不十分 ⚠️

状況: この洞察を伝えたClaude は「完全に正しい」と判断し、コード修正を行いました。
発見: 新しいコードは
```
fetch
```
と
```
go
```
が共有するメソッド全体に影響を与えるおそれがありました。

最終的な半自動的修正 ✅

判断: 変更を広範に適用するのではなく、特殊ケースを
fetch
コマンドに限定することが必要だと気づきました。

実装方針:

FetchCommand#parse()

内で独自の実装を行うことで、他のコマンド（

go

）の「as 変換表現」の使用を阻害しません。

parser.pushFollow("as");
try {
  var url = parser.parseURLOrExpression();
} finally {
  parser.popFollow();
}

if (parser.matchToken("as")) {
  // ... 変換処理
}

テスト生成の支援

AI の役割: 既存のテストスイートに加え、バグを示すケースと修正後の正常動作を確認するための焦点化されたテストを自動生成しました。
効果: AI は特に「テスト生成」において人間をサポートする領域で効果を発揮しました。

教訓：AI 依存のリスクと管理

AI の能力と限界

得意分野:
- 根本原因の特定（調査）。
- テストケースの生成と検証。
苦手分野:
- コードベースに適合する「清潔な」解決策の考案。
- 技術的負債（不必要なハックや状態管理）の回避判断。

「おとぎ話の弟子」への戒め

AI が提案した最初の解決策を盲目的に受け入れることは禁物です。
開発者は：
1. プロジェクトのアーキテクチャを深く理解しておく。
2. AI と対話し、適切な解決策を見極める。
3. AI が生成したコードやテストを検証する。
この姿勢は「おとぎ話の弟子」になるのを防ぎ、開発者を**「大魔法使い」**のような立場に据えます。

「Vibe コーディング」との対比

AI の力を過信して現状を知らないままコードを書く「Vibe コーディング」に対し、人間がインプットし、思考し、判断するプロセスは不可欠です。

補足：AI と高齢開発者

著者（50 歳）の経験に基づく考察です。

AI が解決する問題

記憶力の低下: プロンプトを適切に与えることで、過去の知識を迅速に再構築できます。プロジェクト間での切り替えが格段に効率的になります。
長時間労働の困難さ: 若手開発者でも追うのが難しいペースで作業を行えます。Claude が生成したテストスイートは著者が自らのエネルギーで書くよりも広範でした。

懸念点：知能の退行加速

AI に頼りすぎることは、個人の全体的な知能の退行を促進する可能性があります。
これは自然な加齢現象ですが、依存度が高まれば過程が早まる危険性があります。

結論

AI と開発者がループ内で協力するのは、合理的な能力を持つ人間にとって価値があります。しかし、AI エージェントに最初（または二番目）の解決策を盲目に受け入れることは重大なリスクとなります。

本稿は、独自の考えや戦略を形成する重要性を示唆しました。技術的なバグ修正においては、アーキテクチャを熟知した人間が主導権を握り、AI を最強のアシスタントとして活用することが、複雑性の制御において最も有効な手段であると考えられます。

AI の活用：具体的な事例

Japanese Translation:

Text to translate