言語的技術的負債とは、「化石化した間違い（fossilized errors）」の蓄積です。これは、学習の初期段階で理解されるのに「十分」だったために、繰り返し犯してしまう文法的な間違いのことです。「クイック＆ダーティ（早くて汚い）」なコードを書けばMVPをより早く出荷できますが、将来のスケーラビリティをブロックする脆弱なコードベースを作成してしまうのと同様に、「私ターザン、あなたジェーン」のような文法に頼ることは、C1レベルの流暢さに到達するのを妨げる硬い天井（ハードシーリング）を作り出します。中級の停滞期（プラトー）を打破するには、新機能（語彙）の獲得をやめ、既存のコードベースのリファクタリングを開始する必要があります。
失敗のアーキテクチャ：「十分」がバグになる仕組み
ソフトウェアエンジニアリングでは、しばしばトレードオフを行います。締め切りに間に合わせるために、変数をハードコーディングしたり、ユニットテストをスキップしたりします。これを技術的負債と呼びます。後で修正すると約束しますが、多くの場合、そうしません。
言語学習でも同じプロセスが起こります。初めてベルリン、ロンドン、またはワルシャワに引っ越したとき、あなたの目標は生存でした。あなたは「形式（Form）」よりも「意味（Meaning）」を優先しました。
もしあなたが「私、行く、店、昨日」と言っても、店員は理解してくれました。
結果：トランザクション成功。
脳のログ：「成功！この構文は機能する。本番環境（プロダクション）に保存。」
ここでバグが機能（フィーチャー）になります。コミュニケーションが成功したため、脳は間違った文法を化石化させてしまいました。数年後、過去形のルールを知っていても、正しいライブラリにアクセスする前に、脳はキャッシュされた間違ったバージョン（私、行く）を実行してしまいます。
なぜネイティブスピーカーは私を訂正しないのか？（「寛容なブラウザ」問題）
あなたは疑問に思うかもしれません。「私の文法がそんなにひどいのなら、なぜ誰も教えてくれなかったの？」
答えは、人間が入力を処理する方法にあります。ネイティブスピーカーは、現代のウェブブラウザのように振る舞います。壊れたHTML（閉じタグがない、ネストが悪い）を書いても、Chromeはクラッシュしません。あなたが何を意味したかを推測し、とにかくページをレンダリングします。人間も同じことをします。彼らは「礼儀正しいブラウザ」なのです。
あなたが言う：「椅子はベッドの近くだ。」（不自然な助詞）
彼らが聞く：「椅子はベッドの近くにある。」（脳内補正）
Shehadeh（2003）の研究によると、学習者の間違いの3分の1以上が、自然な会話の中で全く指摘されないことがわかりました。礼儀正しくすることで、会話パートナーは意図せずあなたの技術的負債を増やしているのです。彼らはあなたの壊れたコードを「検証済み（Verified）」としてマークしています。
リファクタリングのワークフロー：3ステップのプロトコル
「ただもっと話す」だけでは、化石化した間違いを修正することはできません。それは単にバグのあるコードをより頻繁に実行しているだけです。専用の「リファクタリング・スプリント」が必要です。これは、「監査（Audit）、分離（Isolate）、パッチ（Patch）」メソッドを使用してスピーキングをデバッグするための手動プロトコルです。
ステップ1：監査（ロギング）
読んでいないコードをリファクタリングすることはできません。話している間、脳は自分の声を自動修正してしまう（音韻ループのレイテンシ問題）ため、外部ログが必要です。
アクション：あなたの一日について2分間自由に話しているところを録音します。
レビュー：録音を聞きます。意味を聞かないでください。構文（シンタックス）を聞いてください。
出力：聞こえたすべてのエラーを書き留めます。これがあなたのバグバックログです。
ステップ2：バグの分離（スコープ管理）
一般的な失敗モードは、一度にすべてを修正しようとすることです。これは認知的過負荷（Stack Overflow）につながります。
アクション：バックログから再発するエラーを1つ選びます（例：「彼と彼女の混同」や「三単現のsの忘れ」）。
ルール：このスプリントでは、他のすべてのエラーを無視します。この単一の関数のパッチ適用にのみ集中してください。
ステップ3：ユニットテスト（ドリル）
コードでは、ユニットテストは特定の関数がさまざまな入力の下で期待どおりに動作することを確認します。文法のためのユニットテストを構築する必要があります。
アクション：「強制出力」ドリルを作成します。
例：バグが過去形の場合は、昨日について10の文を書きます。それらを声に出して読みます。次に、昨日について10の新しい文を自発的に生成しようとします。
合格基準：ためらうことなく、正しい構造を10回連続で生成できますか？できない場合、リファクタリングは失敗しました。ロールバックして繰り返します。
コードレビューを自動化できますか？（「リンター」ソリューション）
上記の手動ワークフローは機能しますが、退屈です。自分自身がQAエンジニアになる必要があります。実際の開発環境では、構文エラーを手動でチェックしません。リンター（Linter）またはコンパイラを使用します。
これが、私たちがDialogoVivoを構築した理由です。私たちは言語学習の「監査」と「ユニットテスト」のフェーズを自動化したかったのです。
私たちは、検証エージェント（Validation Agent）を、あなたの話し言葉に対する厳密なコンパイラとして機能するように設計しました。礼儀正しい人間（バグを無視する）とは異なり、検証エージェントはリアルタイムでエラー例外をスローします。
- リンター：DialogoVivoのシナリオで話すと、AIが構文を分析します。「私、行く、店」と言うと、シミュレーションを一時停止します。
- エラーログ：特定の差分（diff）を強調表示します：期待値「行った」、検出値「行く」。
- ドキュメンテーション：エラーが発生した理由を母国語で説明し、知識のギャップに即座にパッチを適用します。
会話練習を社会的相互作用ではなくシミュレーションとして扱うことで、技術的負債を返済するための安全な環境を作り出します。シミュレーターでプログラムを50回クラッシュさせることができるので、本番環境（実生活）にデプロイするときには、コードはクリーンに実行されます。
スピーキングをリファクタリングする準備はできましたか？
バグのあるコードのデプロイをやめましょう。AndroidでDialogoVivoをダウンロードして、今日から最初の診断シミュレーションを実行してください。
参考文献：Shehadeh, A. (2003). Learner output, hypothesis testing, and internalizing linguistic knowledge.