【この記事の3行まとめ】

NotebookLMのチャットUIにおいて、配列のインデックス [0] などが消失・改変される仕様が存在する
AIは正しいコードを出力しているが、出力でデータが破壊されるため、コピペすると論理バグを招く
利用者はこの状況を良く理解し、自衛策を講じる必要がある

(For English readers: #english-summary/ 英語要約・証拠画像へのリンク)

目次 ※時間がない方は4からお読みください

1. はじめに：AIと歩んだ開発の記録
2. Geminiが薦めた「監査役」としてのNotebookLM
3. AIが「正しいコードを出力しない」チャット画面の「仕様」
4. チャット欄の危険な挙動
5. 「善意の共有」が招く無意識の事故
6. 現在の私たちにできること

1. はじめに：AIと歩んだ開発の記録

私は個人でアプリを開発しています。開発のきっかけは、Geminiでプログラム知識がなくても作りたいゲームやアプリを制作できることを知ったこと。Geminiを触ったのは、この時が初めてでした。

手始めに、読み取った文章を「早押しクイズ風」に表示する、簡単な日本語の設計書をGeminiに送信しました。すると、おおよそながらちゃんと動くアプリがGeminiのCanvasのプレビューに表示されました。「ついにAIもここまでできるようになった」と感動しましたが、その後の開発は最初に想像していた「日本語で伝えるだけで全部作ってくれる」というAI開発とは異なるものでした。

最初はGeminiに追加したい機能をどんどん伝えて、コードの全文を出力させていました。ところが、開発が進むにつれて追加したはずの機能が消えていたり、たまにゲーム全体が別物に改変されて出力されてしまうという問題に直面しました（コード行1000前後）。

AIとあれこれやり取りするうちに、修正箇所の前後数行を特定して「削除範囲」と「貼り付けコード」を出力させる、コード全体を書き換えさせないスタイルにたどり着きました。さあ、無限の修正指示とコピペ作業の始まりです！「（思い描いてたAI開発ってこんなんだっけ……？）」

2. Geminiが薦めた「監査役」としてのNotebookLM

制作が進んで、コードのロジックも複雑になってきました。コード行数は2000行に迫るようになり、GeminiのCanvas上のコード把握も怪しくなってきたころ、Geminiから提案を受けました。

「ソース全体を把握できるNotebookLMで監査すれば便利！」（意訳）

このとき初めて存在を知ったNotebookLMですが、使ってみると確かに便利そう。AIも同じGeminiだし、Canvas側で怪しくなっていたコードの全体像把握もできていそうです。さあ、Canvasで出力された修正指示書をソースに読み込ませてNotebookLMで監査させる、往復運動の始まりです！（思い描いてたAI開発は地平のかなた）

少し面倒でしたが、この手法は効果的でした。指示書内容に問題があるとちゃんと指摘されるし、（頼んでもいないのに）修正コードも出力してくれました。コード全体から不具合調査もできます。アプリ開発は順調なはずでした。しかし、その信頼を根底から揺るがす事実が発覚します。

3. AIが「正しいコードを出力しない」チャット画面の「仕様」

アプリの不具合をNotebookLMで検証させたところ、原因を特定して削除範囲と修正コードが出力されました。しかし何かがおかしい？

画像（完全に同じに見える削除範囲と貼り付けコード）

チャットで何が違うのかと聞くも、謝罪して出力されるコードはまた完全に同一のコード。別の方法で聞き出すと、どうやら出力に欠落があるらしいことを突き止めました。

画像（コードに''が欠落しているらしい ''って何だ？）

しつこくやり取りをして、何とか言葉で説明させると。

画像（ついに欠落していた文字が[0]であると判明）

AIが出力しようとしていた[0]が、チャット画面上から忽然と消えていたのです。技術者の方には何が欠落していたかは自明なのでしょうが、苦労しました。

これまでも同様に消えていたのではないかと疑い、全体をチェックしたところ……。

画像（発覚する３件の[0]欠落による不具合）

監査を行う場でコード全体を脅かす改変が静かに行われていたという、衝撃の事実でした。

4. チャット欄の危険な挙動

その後の検証の結果、判明した挙動は以下のものでした。

・ソース画面（Source View）: アップロードしたファイルそのものを表示する画面では、記述は正しく表示されている。
・チャット画面（Chat UI）: AIがソースを引用したり、回答を生成したりする際、特定のブラケット表記（[0]、[100] など）がUI側のフィルターによってひっそりと削除され、「データが欠落した状態」でユーザーに提示される。

例えば、ソースに question[0] と記述されていても、それを引用したチャット画面では question とだけ表示されます。正しいコードをチャット欄で指示しても、コードブロック内の表記であっても、AI側から出力した[ ]に囲まれた数字表記は消失する可能性があります（特に[0]の消失が強く働くようです）。

これから示す画像では、AIが出力しようとした文字の後ろに日本語説明が加えられています。手前に説明している文字が表示されていない場合、その内容が消失したということです。

画像（チャット欄表示テストの内容ゼロは[ ]ごと消え他の数字は引用リンクに）

これは単なる表示崩れではありません。チャット上でのAI（Gemini）は「指示通りに出力した」と明言しますが、その直後に表示されるコードは一部が消失しています。

AIが正しいコードを出力しようとしているのに、ユーザーが見る画面だけが正しくないという極めて特殊、かつ危険な状態です。UIに問題があることの動かぬ証拠です。

画像（謝罪するGemini 悪いのは君じゃない）

NotebookLMにおける現在の挙動を確認すると、「常に消えるわけではない」という極めて不安定な状態にあります。単独の状態ではほとんど消える[0]も、周りの記述によっては残ることがあります。この「１回は正しく表示された」という経験が、次の瞬間に起きる「静かなる改変」への警戒心を奪う結果になりかねません。

・特定のインデックスに現れる挙動
[0]は完全に消失する一方で、[1] はソースへのリンク（青文字）に化ける、あるいは両方とも残るなど、一貫性のない挙動を示します。ソースとしてアップロードしている数も影響する可能性がありますが、正確にどういった場合に消えるのかは定かではありません。

・「動いてしまうコード」への書き換え
画像で示した通り、UIは単に文字を隠すだけでなく、プログラムの論理を「文法的には正しいが、意味が異なるもの」へとひっそりと書き換えます。技術者の方なら危険性を正しく理解できるのではないでしょうか。

例: data[i][0]（要素の参照） → data[i]（リスト全体の参照）
この書き換え後のコードはPythonとして有効であるため、実行時にエラーを吐かずに「意図しないデータ」を処理し続けます。これにより、バグの発見は目視以外では不可能に近いものとなります。

・標準的な回避策（エスケープ）の無力化
通常、Markdownの表示不備はバックスラッシュ（\・円記号）によるエスケープで回避可能ですが、現在のNotebookLMはこの回避手段も不安定なようです。

画像（バックスラッシュによる回避でも表示されていない連続数字も引用リンクに）

バックスラッシュによるエスケープで表示されている例もあります。

画像（バックスラッシュで表示されないことに驚くGemini 赤丸部分は表示されている）

ソースから読み込んだコードをそのままチャット欄に表示させる指示を行った場合、バックスラッシュによる回避が機能せず、消失する場合もあることを確認しています。

追記：その後の検証の結果、上記の画像のようにコードブロックとして表記している場合、バックスラッシュで挟んだ\[0\]表示はその通り出力されるようです。しかし、手前のみにバックスラッシュを入れた\[0]は、バックスラッシュのみを残してコードブロック内でも[0]が消失します。一方で、地の文はバックスラッシュを入れても一様に消失します。

このことから、AIが「 [ + 数字 + ] 」という３連続した文字列を出力する場合、それを検知して消失や改変が起きるようです。コードブロックでは\[0\]表示は残るが、\[0]の場合は連続する文字列となるため[0]部分が消失。地の文ではエスケープ処理が先に行われてからAIが出力をするため、\[0\]を[0]として出力することで消失が起きます。

5. 「善意の共有」が招く無意識の事故

当初はこれを単なる表示のバグだと思っていました。しかし、NotebookLMの「共有機能」を考えた場合、脅威の質が一変します。

仮に、チーム内で「公式な設定手順」として config[0] を含むノートを共有したとします。共有を受けたメンバーがチャット入力でコードを出力させた際、画面には [0] が欠落した「動かない（あるいは予期せぬ動作をする）コード」が表示されます。

画像（堂々と[0]を欠落して引用 UIが出力を妨げている）

それを見た人はソースからの単なる引用として内容を疑わず、そのままコピペして実行してしまう可能性は非常に高いでしょう。「善意の共有」によって利用者が疑念を挟まずに被害が拡大するという、重大な事態を招きます。

6. 現在の私たちにできること

ユーザーはこの情報を知り、自衛する必要があると判断しました。コードを扱うNotebookLMユーザーの皆さまへの注意喚起として、不格好ながら内容をまとめて公開するという対応をいたしました。

一般的なAIサービスには「AIは間違えることがある」という免責事項があります。ところが、今回のケースはAI（Gemini）自体は正しい回答を出力しようとしています。AIのハルシネーションではないのです。

画像（左はソース内容右でAIは「そのまま表示」と明言するが、同じように表示されていない）

現在はユーザーが「特定の文字列が消えていないか」を常に疑い、手動でチェックを強いられるのが現状です。AIの推論ミスであればユーザーがプロンプトで修正できますが、UIの欠陥によるデータの改変はユーザー側でコントロールできません。

現時点での回避策
現在の状況をよく理解し、ユーザー側で身を守るしかありません。

案１．NotebookLMにコードを出力させない: ロジックの整理や仕様書の読み込み、コードを表示しない提案などに留め、具体的なコード生成はメインのGeminiアプリ等の別環境で行う。

案２．厳密な目視チェック: NotebookLM上でコードを出力させた場合は、絶対にそのままコピペせず、必ず「ソース」画面と一字一句照らし合わせて確認する。プログラム初心者にとって、この案が困難であることは言うまでもありません。

案３．[]内にスペースを入れる表記で出力させる。[ 0 ]この表記だとチャット欄に表示されることが分かりました。しかし、コードの見た目が崩れること、NotebookLM側の仕様だけのためにここまでする必要はあるのかは、判断の分かれるところでしょう。

AIを活用してコーディングを行うすべての人間にとって、この「サイレントな破壊」は、目視での検証すら困難にする深刻な罠となります。皆さまもNotebookLMを利用する際は、この挙動に十分ご注意ください。

プログラム知識にうといところもあり、技術者様から見て疑問点や間違いもあると思われますがご容赦願います。私と同じような被害に遭う人が少しでも減るよう、取り急ぎ執筆いたしました。

この記事がAIによるコーディングを行う皆さまの助けになると幸いです。

※【追記：2026/02/22】
外部コミュニティのユーザーより、英語環境でも同様の挙動が発生するとの報告をいただきました。

※【追記：2026/02/23】
この仕様はGemini Deep ResearchのUIでも同様に発現することを確認しました。

For English Speakers

Important Notice: Deletion of `[0]` and Array Index Alteration in NotebookLM

Please be aware of a specific behavior in the NotebookLM Chat UI that can silently alter your source code and logic.

Summary of the Issue

Silent Deletion: In the Chat UI, bracketed notations like [0] are often stripped or mutated.
Not an AI Hallucination: The AI (Gemini) generates the correct code, but data is destroyed at the time of output. This leads to critical logic bugs when the code is copied.
Self-Defense Required: Users must be well aware of the current situation and protect themselves, as the UI's data alteration cannot be controlled by the user.

Technical Details
In the output, specific strings such as [0] or [100] are stripped. For example, data[i][0] may be displayed as data[i]. Because the resulting code remains syntactically valid, it continues to run without error while processing unintended data, making these bugs extremely difficult to detect.

Current Workarounds

Avoid Code Output in NotebookLM: Use NotebookLM for auditing or summarization, but use the main Gemini app for actual code generation.
Strict Visual Verification: Always compare the chat output character-by-character with the "Source View."
Format Alteration: Using spaces inside brackets (e.g., [ 0 ]) prevents the UI from stripping the text.