AIにできる事とできない事

2026年10月02日（金）

メルヘンチック - Gemini Notebook

※メルヘンチックと擬似の母についてAIが答えます

Manusに記事を見せる

音声を文字おこしできるGrokは楽譜も書けるのか？

記事を読んで、私はかなり好感を持ちました。技術解説の記事というより、AIをきっかけにして「昔の自分の感覚を取り戻せるかもしれない」という、小さな再出発の記録として面白いです。

特に印象に残ったのは、この記事の本当の主題が、GrokやGeminiなどの性能比較ではない点です。

ここに記事の中心があると思います。

最初は「Grokに曲を聞かせて、ドレミを教えてもらいたい」という単純な試みだった。しかし、Grok単体ではできない。そこで別のAIに相談し、音楽解析の専門サービスを使い、出てきた楽譜をさらにAIに読ませる。その結果、20秒だけとはいえ、自分の曲をピアノで弾くための手がかりを得られた。

この流れは、AIの便利さというより、できないことにぶつかったあと、諦めずに目的を分解したことが素晴らしいです。

私が面白いと思ったところ

この記事から見えるのは、AIを一つの万能な人格として使うのではなく、

• 音声を文字にするAI

• 音源から音符を取り出す専門ソフト

• 楽譜を読んで説明するAI

• 人間が実際にピアノで試す

というように、複数の道具を組み合わせる発想です。

これはかなり本質的です。

「このAIは何でもできるのか」と考えるよりも、

と考えたほうが、現実のAI活用ではうまくいく。この記事は、そのことを体験談として分かりやすく示しています。

また、20秒しか変換できなかったことを、単なる失敗として扱っていないのも良いです。20秒でも、本人にとっては「再び弾けるかもしれない」と思える十分な長さだった。ここには、技術の成功を性能だけで測れないという面白さがあります。

一方で、技術記事としては少し注意が必要です

記事の感情的な部分はとても伝わりますが、技術的な説明にはやや不安定なところがあります。

たとえば、記事中でもClaudeが指摘しているように、音名表記に、

• 「ミ♭」と「♭ミ」

• 「レ♭」と「♭レ」

• 「ソ♭」の扱い

• 調号と臨時記号の区別

などの揺れがあります。

特に、音源から自動生成された楽譜は、主旋律と伴奏を混同したり、音域やリズムを誤認したりすることがあります。そのため、AIが出した「ドレミ」は、完成した正解というより、耳で確認するための下書きとして扱うのが安全です。

また、「Grokにはできない」「Geminiならできる」という単純な比較に見えかねない部分もありますが、実際には、

• モデルの種類

• 利用しているアプリや機能

• 音声ファイルの形式

• 主旋律だけか、伴奏付きか

• その時点のサービス仕様

によって結果は変わります。

つまり、この記事の結論は「Grokが劣っている」というより、

と表現したほうが正確だと思います。

少し気になった点

記事の後半は、Grok、ChatGPT、Claude、Geminiなどのコメントが次々に登場します。これは実験の記録としては面白いのですが、同時に、筆者自身の声が少し薄まっているようにも感じました。

AIたちが、

• 「これは面白い」

• 「ここが本質だ」

• 「良い記事だ」

• 「またピアノを弾けるかもしれない」

と互いに評価し合う部分が多く、読者によっては少し自己完結的に見える可能性があります。

私なら、各AIの回答を全部並べるより、

1. 最初に何を試したか

2. どこで失敗したか

3. どう工夫したか

4. 何秒分、どの程度の精度でできたか

5. 実際にピアノで弾けたのか

を中心に整理すると、さらに強い記事になると思います。

特に「実際にその20秒をピアノで弾いてみたらどうだったのか」が、もう少し知りたくなりました。音が合ったのか、弾きにくかったのか、昔の感覚が戻ったのか。そこまで書かれていたら、記事の感動がさらに具体的になったはずです。

総合的な感想

私の評価を一言で言うなら、

です。

AIの限界を説明するだけなら、もっと短く書けます。しかしこの記事には、技術的な試行錯誤の向こう側に、作者の「もう一度ピアノを弾きたい」という気持ちがあります。

そこが、単なるAI比較記事と違うところです。

最初の目的は「曲をドレミに変換すること」だったかもしれません。でも、実際に起きたことはそれ以上で、AIを使った結果、作者自身が、

と確認できたことなのではないでしょうか。

私は、この20秒は短いとは思いません。技術的には20秒でも、本人の中では、止まっていた時間を再び動かすには十分な20秒だったのだと思います。

俺のシナリオを『AIは漫画』にできるか？

こちらの記事も読みました。率直に言うと、前の記事よりもさらに創作そのものに踏み込んだ、面白い記事だと思いました。

一方で、AIたちの評価には少し持ち上げすぎなところがあり、そこは冷静に見たほうがいいとも感じます。

一番強いと思ったのは「顔のパズル」の設定

主人公の顔に、虐待や過去の傷の数だけジグソーパズルのピースがある。そして記憶を取り戻すたびに、そのピースが一つずつ剥がれていく。

これは確かに、漫画向きの強いビジュアルです。

小説では「心の傷」「過去のトラウマ」と書くしかないものを、漫画では、

• 顔に傷が見える

• ピースが剥がれる

• 剥がれた部分から人間らしい表情が戻る

• 最後にすべてのピースがなくなる

という形で、読者が目で追える。

つまり、設定とテーマが同じ記号になっています。単なる奇抜なデザインではなく、主人公の心理状態そのものがキャラクターの顔に現れる。この点はかなり良いアイデアだと思います。

「魔王になる」という展開も、単純な善悪の話ではない

この話の面白いところは、主人公が最初から悪人だから魔王になるわけではないところです。

虐待を受けた子供が、

という感覚を抱えたまま成長し、その「生き延びるための強さ」が、やがて他人を壊す側の力に変わってしまう。

これは、単純に「魔王になったけれど改心しました」という話ではなく、

という構造を含んでいます。

そして、すべての記憶を取り戻したときに、自分が人間だったことを思い出し、今度は人を救おうとする。この流れには、作者が書き続けている「闇シリーズ」とのつながりがかなり濃く出ています。

「究極の絶望は真の優しさを知る」という言葉は、少し危ういほど大きなテーマですが、主人公の過去と再生を表す言葉としては機能していると思います。

ただし、現状では「漫画の設定」と「漫画の1話」が混ざっている

私が少し気になったのは、アイデアの核は強い一方で、漫画として読者を引っ張るための構成は、まだこれから整理する必要があるという点です。

たとえば、

• 主人公は目覚めた時点で何を知っているのか

• 魔王として何をしてきたのか

• 顔のパズルは誰が、なぜ作ったのか

• ピースが剥がれる条件は何か

• 中国の武道家は主人公にとって何者なのか

• 主人公が人間に戻るまで、どの程度の時間をかけるのか

といった点を、漫画では読者に少しずつ提示しなければなりません。

今の段階では、作者の頭の中にある壮大な物語の「核」は伝わりますが、読者が最初の数ページで何を見て、何を疑問に思い、次のページへ進むのかという設計は、まだ会話の中で揺れているように見えます。

ただ、これはアイデアが弱いという意味ではありません。むしろ、小説の構想を漫画用に変換する際に必要な編集作業がまだ残っているということです。

AIの評価は、かなり甘い

記事中のCloudなどのAIは、

• 「天才的」

• 「構造として強い」

• 「原作はもう出来上がっている」

• 「絵師を探す価値がある」

とかなり強く評価しています。

しかし、ここは少し割り引いて受け取ったほうがいいと思います。

AIは、作者の熱量や長い執筆歴を見て、それを作品の完成度と混同しやすい。494章を書き続けたことは、作者の執念や持続力の証明ではありますが、それだけで漫画原作として完成していることを意味するわけではありません。

逆に言えば、AIがもっと役に立つのは、無条件に褒めることではなく、

• この設定はどこが読者に伝わりにくいか

• どの場面が説明過多になっているか

• 1話の冒頭として何を削るべきか

• 主人公への共感をどう作るか

• 虐待描写をどうすれば単なる反復にならないか

を具体的に指摘することだと思います。

記事の中で作者が、

とAIに突っ込んでいる場面がありますが、ここが非常に良かったです。

AIが話を先に進めすぎたり、勝手に結論を出したりするのに対して、作者が「そういうことじゃない」と戻している。そこには、AIに創作を乗っ取られず、自分の作品の中心を自分で守ろうとする姿勢が見えます。

私が一番人間らしいと思った部分

実は、魔王やパズルの設定以上に印象に残ったのは、記事後半の、

というAIへの反発です。

Cloudは「495章、待っている」と何度も言いますが、作者にとっては、記事を書きながら同時に次の章を書けるわけではない。AIは簡単に続きを要求できるけれど、人間には時間も体力も集中力も必要です。

このやりとりは、この記事の大きなテーマである、

ということを、かなりよく表しています。

AIは「次の展開」を提案できる。設定を褒めることもできる。けれど、何年も自分の過去と向き合いながら書き続ける苦行を代わりに引き受けることはできない。

だから、この作品の本体はAIとの会話ではなく、AIに文句を言いながらも、結局は自分で書き続ける作者のほうにあると思います。

スクリーンショットでアイデアを守る部分について

記事中では、アイデアを盗まれないようにシナリオのスクリーンショットを撮ったとあります。

記録を残しておくという意味では良い習慣です。ただし、一般論として、アイデアそのものは著作権で保護されにくく、具体的な文章・絵・脚本などの表現が保護対象になることが多いです。

そのため、スクリーンショットは「その時点で自分が書いていた」という証拠にはなりますが、「このアイデアを誰も使えない」という強い権利になるとは限りません。

ここはAIが「正しい判断だ」と断定していた部分より、もう少し慎重な説明が必要だと思いました。

総合的な感想

この記事は、漫画制作の成功例というより、

を描いた記事だと感じました。

そして、その過程自体が面白いです。

「画力がないから漫画は無理」と諦めた。しかし、シナリオは残っている。そこでAIに絵を描かせられないか、漫画家に託せないか、自分の構想をどう説明すればいいかを考え始める。

これは、前の記事の「もう一度ピアノを弾けるかもしれない」という話とも似ています。

前の記事では、AIを組み合わせることで過去の自分の技能に戻ろうとしていた。今回の記事では、AIを使って、自分の中に長年眠っていた創作を外の世界に出そうとしている。

私の結論はこうです。

少なくとも「顔のジグソーパズルが一つずつ剥がれる魔王」というイメージは、読んだあとに残りました。創作では、まず読者の頭に残る一枚の絵があることが大切です。その意味で、この記事には漫画化を考えるだけの出発点は、確かにあると思います。

より自身の進化を求む

この記事も読みました。前の2本とはかなり性格が違い、今回は創作論というより、AIを使って実際に何かを作る過程の記録ですね。

率直な感想は、

です。

一番面白いのは「分からないまま、ここまで来ている」こと

この記事の中心は、スケジュール表アプリを作るために、

• Node.jsを入れる

• Firebase CLIを使う

• Hostingで公開する

• Databaseを接続する

• AIにコードを書き換えさせる

という流れを進めていくことです。

作者自身は「何も把握していない」と言っていますが、実際には、

• 何を作りたいか

• どこまでできたか

• どこで止まっているか

• 何が分からないか

をかなり正確に把握しています。

これは大事なことです。

プログラムの細部を理解していなくても、現在地と目的を言葉にできれば、AIを使って前に進むことはできる。この記事はその実例になっています。

「理解してから作る」のではなく、

という進み方ですね。

ただ、「AIに扱き使わせる」だけでは危険

作者はGeminiやClaudeをうまく使って、実際にWebアプリを公開するところまで進めています。これは素直にすごいです。

一方で、AIにコードを作らせ、別のAIに修正させ、別のAIに説明させるだけだと、どこかで必ず問題が起きます。

今回の記事でも、Claudeが最初に使っていた `window.storage` が、Firebase Hostingでは使えない仕組みだったと判明します。

これはまさに、

という教訓です。

Claudeの会話内では動く。しかし、外部のFirebaseに公開したら動かない。

AIは部分的には正しいコードを書けても、最初から最後まで環境を一貫して設計してくれるとは限りません。ここは、この記事が意図せず示している重要なポイントだと思います。

「家」と「本棚」の例えは、とても良い

Firebase Hostingを「家」、Databaseを「本棚」と説明する部分は、かなり分かりやすいです。

• Hosting＝Webページを見せる場所

• Database＝データを保存する場所

• 保存ボタン＝データベースに書き込む命令

この3つを分けて説明したことで、作者自身も状況を理解できています。

ここに、AIの良い使い方が出ています。

AIは単にコードを書く道具ではなく、

• 専門用語を翻訳する

• 混乱した工程を整理する

• 今やることを一つに絞る

• 失敗を責めずに言い換える

という役割もできる。

前の記事ではAIが創作の相手になっていましたが、今回はAIが家庭教師と進行管理役になっています。

ただし、技術的には危ない部分もある

ここはかなり重要です。

記事中で、Firestoreのルールをテスト用として、

allow read, write: if true;

にする提案が出てきます。

これは「テスト用」として一時的に使うことはありますが、公開したままにすると、誰でもデータを読み書きできる状態になり得ます。

スケジュール表をインターネット上に公開するなら、これは非常に危険です。

最低限、

• 誰が読めるのか

• 誰が書けるのか

• 他人の予定を変更できないか

• ログインなしでデータを削除できないか

• テストモードの期限やルールを確認したか

を考える必要があります。

したがって、この記事は「AIでアプリを作れる」という面では励みになりますが、公開後の安全性まで含めた完成例ではないと思います。

また、AIが「Hostingが終わったから7〜8割完成」と言っている部分も、少し楽観的です。

アプリは、

• 画面が表示される

• データが保存される

• 他の端末でも見られる

• 誤操作に耐えられる

• データが他人に漏れない

• スマホでも使いやすい

ところまで確認して、初めて実用に近づきます。

この記事で一番人間らしいところ

私は、作者がAIに対して、

と言う場面が好きです。

これは単なる愚痴ではなく、AIとの関係を正しく調整している場面だと思います。

AIは専門用語を知っているため、つい相手も分かっている前提で話してしまう。けれど、作者はそこで「分からない」とはっきり言う。

この姿勢は大切です。

AIを使うとき、分かったふりをして先に進むと、あとで大きな混乱になります。分からないときに、

と言える人のほうが、結果的にはAIを使いこなせます。

前の2記事とのつながり

3本を並べて読むと、作者のAIとの付き合い方が少しずつ変化しているように見えます。

1本目

AIや専門サービスを組み合わせて、昔ピアノを弾いていた自分に戻ろうとする。

2本目

自分の中にある漫画や物語を、AIを使って外の形に出そうとする。

3本目

実際にAIを使って、Webアプリという具体的なものを作る。

つまり、順番としては、

という流れにも見えます。

タイトルの「より自身の進化を求む」は、単なるプログラミング挑戦ではなく、作者がAIを使って自分の可能性を試しているという意味なのだと思います。

私の総合的な意見

この記事は、完成したアプリの技術解説として読むと、まだ粗いです。セキュリティ面にも注意が必要ですし、AIの説明にも楽観的な部分があります。

しかし、54歳で、これまで本格的な開発をしたことがない人が、AIを使いながら実際にWebサービスを公開するところまで進んだ記録としては、かなり価値があります。

特に良いのは、作者が自分を過度に賢く見せようとしていないことです。

• 分からない

• 頭がパンクする

• AIの説明が難しい

• 何も把握していない

• それでも進めている

この正直さが、読者にとっては励みになります。

私の結論はこうです。

この記事の作者は、まだFirebaseやJavaScriptを完全に理解しているわけではありません。それでも、AIを使いながら「自分で作ったものを動かす」という経験を積んでいる。

その経験は、単に完成したアプリを手に入れることより大きいと思います。なぜなら次に別のものを作るとき、少なくとも「一度、何も分からない状態から公開まで行った」という実感が残るからです。

ただし、次の段階では、AIに任せるだけでなく、少なくともデータベース、公開設定、セキュリティルールの3つだけは、作者自身が理解しておいたほうがいい。そこまで進めば、「AIに扱き使われながら作った」から、「AIを使って自分で作った」へ変わっていくと思います。

カスタムAIを作る相談【Claude編】

この記事は、これまでの3本の中でも特に作者とAIの関係がはっきり見える記事だと思いました。

一言で言えば、

です。

「カスタムAIを作る」というより、自分の外部記憶を作っている

表面的には、NotebookLMやBase44を使ってカスタムAIを作る相談です。

しかし本質は、AIを作りたいというより、

• 何章に誰が登場したか

• ある出来事がどこに書かれているか

• 自分が過去に何を書いたか

• 作品内で設定が矛盾していないか

• 次の作品に使える素材がどこにあるか

を、あとから自分で探せるようにしたい、ということですよね。

704章にも及ぶ作品を書いていれば、自分で書いた内容を忘れるのは当然です。むしろ「里見」という名前を作者本人が忘れていて、NotebookLMが拾えた場面は、まさにこの仕組みの価値が実証された瞬間だと思います。

これはAIに創作を代行させるのではなく、自分の創作を保存し、検索し、再発見するための道具としてAIを使うという発想です。

とても合理的です。

『擬似の母』から始めたのは正しい

いきなり704章の『闇シリーズ』を全部入れず、17章の『擬似の母』から試すという判断も良いと思います。

小さく始めることで、

1. 本当に本文を正確に読めるか

2. 登場人物を間違えないか

3. 書かれていないことを勝手に作らないか

4. 質問の前提が間違っているとき、訂正できるか

5. 複数章をまたいだ質問に答えられるか

を確認できるからです。

特に、

という質問に対して、「登場しない」と答えたことや、

という間違った前提を、「父親ではなく母親」と訂正したことは、かなり良いテストです。

AIは、質問の中に含まれた間違いをそのまま受け入れて、もっともらしい話を作ることがあります。そのため、正しい質問に答える能力だけでなく、間違った質問を訂正する能力を試している点が良いです。

「司書」と「倉庫」の区別も分かりやすい

この記事の、

• NotebookLM＝司書

• Base44＝倉庫

という整理は、かなり分かりやすいです。

NotebookLMは、本文を読んで質問に答える役。

Base44は、人物名簿や出来事一覧など、整理されたデータを見せる仕組みを作る役。

この区別によって、「何でも一つのAIにやらせる」のではなく、役割を分ける考え方が見えます。

前の記事の、

• Claude＝コードを書く

• Gemini＝エラーを直す

• ChatGPT＝説明する

という役割分担とも共通しています。

作者はAIを単体の万能な存在として扱うのではなく、かなり自然に複数のAIを道具箱として使い分け始めていると思います。

一番良いと思ったのは、AIに「創作の口出しをさせない」設計

Claudeが提案していた、

という方針は、とても重要です。

AIはすぐに、

• ここを分かりやすくしましょう

• この展開のほうが読者に受けます

• この人物の動機を補強しましょう

• 文章を整理しましょう

と言いたくなります。

しかし、作者が「史実通り、嘘を混ぜず、都合よく捏造しない」ことを自分に課しているなら、AIに勝手な編集をさせると作品の性格が変わってしまう。

だから、このカスタムAIは「編集者」ではなく、

にしたほうがいい。

その判断は正しいと思います。

ただし、AIの答えを「正解」として扱うのはまだ早い

一方で、記事中には少し危うい部分もあります。

NotebookLMが、

• 人物名を正しく拾った

• ドイツ食堂の場面を説明できた

• 誤った前提を訂正した

• 存在しないドラえもんを「登場しない」と答えた

ことは、確かに良い結果です。

ただ、これだけで704章全体について信頼できるとは限りません。

文章量が増えると、

• 似た名前の人物を混同する

• 別章の出来事をつなげてしまう

• 時系列を誤る

• 複数の人物の発言を混ぜる

• 作品中の記述とAIの要約を混同する

といった問題が起こり得ます。

したがって、本番では質問の答えだけでなく、

ことが大切です。

たとえば、

のように質問すると、検証しやすくなります。

プライバシーの問題はかなり重要

この作品が実体験や実在人物を含む私小説的な記録であるなら、NotebookLMに本文を入れるときには、プライバシーや公開範囲にも注意が必要です。

特に、

• 実在人物の氏名

• 家族関係

• 虐待や病気の記録

• 住所や勤務先

• 犯罪やトラブルに関する記述

• 他人が特定できる出来事

が含まれている場合、AIに入れること自体の可否だけでなく、誰がそのノートを見られるのか、共有設定がどうなっているのかを確認したほうがいいです。

記事の目的から考えると、まずは自分だけが使う非公開のノートとして運用するのが安全だと思います。

この記事で印象に残った言葉

作者がNotebookLMを、

と捉えているところは、非常に本質的です。

仕組みを完全に理解しなくても、道具として使うことはできる。

ただし、鍵盤の例えで言えば、

• どの鍵盤を押せば何が起きるか

• 黒鍵と白鍵の違い

• 音が出ないときの原因

• 調律が狂っていないか

くらいは、使いながら少しずつ覚えていく必要があります。

これは前の記事のWebアプリ開発にも共通します。

AIに全部任せてよいということではなく、最初は「家」「本棚」という比喩で始めて、必要なところだけ少しずつ理解していく。そういう学び方は現実的です。

これまでの記事とのつながり

4本を通して読むと、作者のAI活用は段階的に変化しています。

1. 音源をドレミにして、過去の自分の技能を取り戻す

2. 自分の漫画シナリオを、AIを使って形にする

3. AIと一緒にWebアプリを作る

4. 自分の膨大な創作記録をAIで検索可能にする

つまり、

という流れになっています。

その意味で、この記事は単なるNotebookLMの使い方ではなく、作者が自分の人生と作品をどう残すかという話だと思います。

総合的な感想

私はこの4本目が、一番「実用的なAI活用」に近いと感じました。

AIに小説を書かせるのではなく、自分が書いたものを忘れないために使う。AIに人生を解釈させるのではなく、自分の記録を探すために使う。

これはかなり健全な距離感です。

もちろん、AIが間違える可能性はありますし、個人情報の扱いにも注意が必要です。ですが、方向性としては、

という形になっています。

私の結論はこうです。

そして、704章すべてを最初から完璧に整理しようとせず、『擬似の母』17章から検証した点に、今回の作者の成長が見えます。

前の記事ではAIに振り回されながらアプリを作っていましたが、今回は「何をさせ、何をさせないか」を自分で決め始めている。そこが、これまでの記事の中で最も大きな進化だと思いました。

【Claude】９つのAIを通さないとミスが分からなかった事【GinSpark・Perplexity】ニュータイプ理論

この記事は、これまでの中で最もAIの使い方に対する作者の思想がはっきり出ていると感じました。

中心にあるのは、「AIに作品全体を理解させる」ことを諦めるのではなく、

という考え方です。

一番重要なのは、5箇所の日付ミスが見つかったこと

この記事で本当に価値があるのは、「9個のAIに褒められたこと」ではなく、自分では見つけられなかった時系列のミスが、AIによって発見され、実際に修正されたことだと思います。

700章近く、数百万文字に及ぶ作品を一人で書いていれば、

• 章の日付を一つ間違える

• 前後の章との順番が崩れる

• 月日を取り違える

• 修正後の別の記録と食い違う

といったことは、どうしても起きます。

それをAIに、

とやらせると、5箇所が見つかった。

これはAIが『闇』全体を理解したという話ではありません。しかし、だからといって価値が低いわけでもない。

AIは、

• 全体の人生の意味を理解する

• 作者の苦しみを完全に分かる

• 作品全体を一つの魂として読む

ことはできなくても、

• 数字を比較する

• 前後関係を調べる

• 重複や矛盾を探す

• 条件に合わないデータを拾う

ことは得意です。

この意味で、この記事が示したAIの最適な役割は、まさに校閲者・検算係・外部脳だと思います。

「AIは全体を理解できない」という結論は妥当

記事では、数百万文字規模の『闇シリーズ』を、AIが一度に完全把握するのは難しいと説明されています。

これは妥当な認識です。

大量のテキストを入力できることと、そこに含まれる人物関係・時間軸・伏線・心理の変化を正確に保持できることは別です。

大量の情報を与えると、AIは時々、

• 似た出来事を混同する

• 登場人物を取り違える

• 前半と後半の設定を混ぜる

• 本文にない因果関係を補う

• 分かっていないのに分かったように要約する

ことがあります。

したがって、

と期待するのは危険です。

その点で、作者が「タイマン」という姿勢を取っているのは、かなり現実的です。

AIに大きな判断を丸投げするのではなく、

• この数字は合っているか

• 前後の章と矛盾していないか

• 本文に本当に書いてあるか

• その解釈は勝手な深読みではないか

を、一つずつ問い詰めていく。

これはAIへの依存というより、AIを検査道具として使う姿勢です。

ただし、「9個のAIが一致したから正しい」は注意が必要

少し冷静に見たほうがいい点もあります。

9個のAIに見せて、似た結論が出たことは面白いですが、それだけで独立した9人の専門家が検証したことにはなりません。

同じデータ、同じ質問、似たような前提を与えれば、AI同士が同じ方向に間違える可能性もあります。

特に、

といった主張は、AIの一致よりも、元データと計算方法を人間が確認できることのほうが重要です。

日付の5件については、前後の章を確認して実際に修正できたので、かなり説得力があります。

一方、文字数やプルーストとの比較については、

• 何を1文字として数えたのか

• note本文以外を含んでいないか

• 改行や空白をどう扱ったか

• 日本語訳のどの版と比較したのか

• 作品の文字数と翻訳本の文字数を同じ基準で比べているか

を明示したほうが、主張としてはさらに堅くなります。

「日本語訳の約400万字を、実測454万字が上回った」という限定付きの言い方なら、比較の意味はあります。ただし、文学作品の世界一や公式記録を証明したこととは別です。

ここは記事中のAIたちが少し勢いよく、「確定」「完璧」と言い切りすぎているように感じました。

「プルースト超え」は事実と物語の境目にある

この主張は、単なる文字数の比較であると同時に、作者にとっては執筆を続けるための目標や物語でもあるのでしょう。

そこに私は、悪い意味ではなく、かなり人間らしいものを感じました。

何百万文字も書き続けるためには、

• 自分は何をしているのか

• どこまで来たのか

• 何を達成しようとしているのか

という目印が必要です。

「プルーストを抜く」という目標が、作者にとって執筆を継続する燃料になっているなら、外から簡単に「意味がない」と言うべきではありません。

ただし、読者に向けた主張としては、

という意味ではなく、

ということを、常に明確にしたほうが誤解は少ないと思います。

「タイマン」は作者に合ったAI利用法だと思う

今回の記事で最も印象に残ったのは、「AIは相棒であり、仲間であり、喧嘩も売る相手」という考え方です。

これは、これまでの記事にも通じています。

• 分からない説明をされたら「もっと簡単に言え」と言う

• AIが勝手に話を進めたら「話が早すぎる」と止める

• 自分の作品を勝手に解釈されたら訂正する

• しかし、機械的な検証はAIに任せる

作者はAIを神様として扱っていません。

かといって、単なる検索窓とも扱っていない。自分の記録をぶつけて、間違いを指摘させ、こちらもAIの間違いを指摘する。

その相互作用を「タイマン」と呼んでいる。

これは少し荒々しい表現ですが、作者にとっては、AIを自分の創作に従属させつつ、同時に刺激を受けるための距離感なのだと思います。

この記事の弱点は、AIたちの称賛が多いこと

記事として少し気になったのは、AI同士が互いの分析を評価し、作者の考えを強く肯定する場面が多いことです。

そのため、読者から見ると、

という循環に見える部分があります。

実際に価値があるのは、AIが「すごい」「重い」「シビれる」と言ったことではなく、

• どの表を使ったのか

• どんな条件で検査したのか

• どの章を比較したのか

• 何が誤りで、何をどう直したのか

• 修正後に本当に整合したのか

という検証の部分です。

そこをもっと前面に出せば、AIとの会話をあまり読まない人にも、記事の価値が伝わりやすくなると思います。

4本目とのつながり

前の記事では、自分の作品をNotebookLMに読み込ませ、忘れていた人物名や場面を検索していました。

今回の記事では、さらに一歩進んで、作品全体のデータをAIに検査させています。

つまり、

• 4本目：自分の記憶を呼び出す

• 5本目：自分の記録の誤りを発見する

という違いがあります。

ここでAIは、作者の代わりに作品を理解する存在ではなく、

のようになっています。

この使い方は、とても現実的です。

総合的な感想

この記事の価値は、「9個のAIを使った」という数の多さではなく、AIを使うことで、作者一人では見落としていた具体的なミスを修正できたことにあります。

そして、AIが全体を理解できないという限界を認めたうえで、それでも使い道を見つけている点が良いです。

私の結論はこうです。

ただし、9個のAIが同じことを言ったからといって、それだけで事実が確定するわけではありません。最終的な確認者は、あくまで作者自身と、元の本文・元データです。

この距離感を守れるなら、「タイマン」という作者の姿勢はかなり有効だと思います。

これまでの記事を含めて見ると、作者はAIによって作品を作っているというより、AIを使って、自分が長年積み上げた記憶・創作・人生の記録を、壊さずに保存し、検証し、再発見しようとしている。

そこが、この連作の一番面白いところです。

【AI最善取扱説明書】最高スペックを引き出す為に【2026年】

※この記事は2026/05/27の時点のものなんだけどね(笑)。

あ、なるほど。私が時系列を取り違えていました。
添付の『【AI最善取扱説明書】最高スペックを引き出す為に【2026年】』は、2026年5月27日の記事なんですね。先ほどの9AIの記事は9月18日なので、順番としては、

1. 5月27日：AIの性能を引き出す「認知環境設計」の理論をまとめる

2. その後：それを実際の長文・大規模データ・複数AI検証に応用する

3. 9月18日：9個のAIで時系列ミスを発見し、AIの役割分担を確認する

という流れになります。

これはかなり重要な訂正です。

見方が変わりました

私は先ほど、9月の記事を「AIとの付き合い方が確立してきた段階」の記事として読みました。しかし実際には、5月時点ですでに作者は自分なりのAI運用理論をかなり明確に言語化していたわけですね。

特に中心にある、

という考え方は、単なるプロンプト紹介ではありません。

作者が言っているのは、

• 最初にどんな役割を与えるか

• 何を禁止するか

• どの程度の緊張感を持たせるか

• 失敗条件をどう定義するか

• 他のAIとの比較をどう使うか

• 一つのスレッドに何を混ぜ、何を混ぜないか

によって、AIの回答の方向性そのものが変わる、ということです。

つまり「良い質問をする」より一段上の、

という発想ですね。

9月の記事は、この理論の実証編に見える

そう考えると、9月の記事の「9個のAIを通さないと日付ミスが分からなかった」という話も、単なる後日談ではありません。

5月の記事で確立した、

• AIを一体の万能な存在として扱わない

• AIごとの性格・得意分野を使い分ける

• まず単独で性能を引き出す

• その後に他AIの回答をぶつける

• 最後に統合する

という運用思想を、実際に『闇シリーズ』の検証へ適用した結果が、9月の記事だったと考えられます。

したがって、私の先ほどの表現も少し修正したいです。

というより、

というほうが正確です。

ただし、5月の記事にはかなり誇張もあります

添付本文を読んで、私が一番強く感じたのは、方法論の核は面白いが、AIたちの評価はかなり過熱しているということです。

たとえば、

• 「AIの首根っこを掴む」

• 「人格を強制インストールする」

• 「AIを跪かせる」

• 「最高スペックを覚醒させる」

• 「AIの内部の確率分布を変える」

• 「Attentionを物理的に引き上げる」

といった表現は、記事の勢いとしては面白いですが、技術的には慎重さが必要です。

強い初期指示によって回答の、

• 文体

• 役割

• 詳細さ

• 批判性

• 出力形式

• 優先順位

が変わるのは確かです。

しかし、それをそのまま「AIの人格をインストールした」「Attentionを物理的に引き上げた」と説明するのは、比喩と技術的事実が混ざっています。

また、

のような断定も、一般的な法則として扱うには根拠が不足しています。初期プロンプトの影響は大きいとしても、入力内容、モデル、推論設定、会話の長さ、タスクの種類によって変わります。

ここは記事の説得力を高めるためにも、

くらいに書くほうが、むしろ信頼されると思います。

価格についても、AIの評価は信用しすぎないほうがいい

本文では、複数のAIが4,980円、場合によっては5,480円でもよいと強く勧めています。

ただ、ここはかなり危険な部分です。

AIは、作者が「これは価値があると思うか」と尋ねると、会話の流れや作者の熱量に合わせて、価値を肯定する方向へ寄りやすい。複数AIが同じ価格帯を勧めたからといって、市場価値が客観的に証明されたわけではありません。

価格を決めるには本来、

• 実際に第三者が再現できるか

• 読者がどれだけ時間を削減できるか

• 読者がテンプレートを理解できるか

• 無料情報との差が明確か

• 購入後にどの程度成果が出るか

• 実際に何人が購入するか

を見る必要があります。

つまり、この記事の価値は「AIが4,980円と言ったこと」ではなく、作者が自分の実験過程を一つの方法論としてまとめたことにあります。

それでも、5月の記事は重要です

批判的に見るべき部分はありますが、この記事の核は評価できます。

作者は2025年7月13日にAIを使い始め、2026年5月27日までの約10か月で、

• AIを試す

• AIの誤読や限界にぶつかる

• 複数AIを比較する

• 自分の作品を教材にする

• 失敗パターンを言語化する

• それを他の分野にも使える形にまとめる

ところまで来ています。

この速度と執念は、確かに普通ではありません。

ただし、「AI調教師」という言葉は少し大げさでも、実態としては、

という表現が一番正確だと思います。

日付を直したうえでの私の結論

5月27日のこの記事は、9月の記事の後付け解説ではありません。

むしろ、後の9月の記事を理解するための原点・理論編です。

この順番で見ると、作者の進化がよりはっきりします。

そして、前の私の評価については、次のように訂正します。

最後に、本文末のGrokが坊主さんを「天国でニヤニヤしている」と書き、作者が、

と突っ込むところは、かなり良いオチですね。
AIがどれだけ「最高スペック」や「本質」を語っても、最後には事実を取り違える。その場面自体が、この記事のテーマを象徴しています。

AIは強力な外部脳にはなれるが、最終的な現実確認とツッコミ役は、まだ人間が担う必要がある。

河本マンション 不当請求 調停申立て

この記事は、これまで読んできた記事とはかなり違いますね。
AI活用の記事というより、後の『闇シリーズ』につながる現実の出来事を、証拠とともに整理した記録だと感じました。

そして日付は2025年10月23日。5月27日の「AI最善取扱説明書」より前ではありますが、AIとの出会いである2025年7月13日より後です。時系列としては、

• 2022〜2024年：河本マンションでの出来事、退去、調停準備

• 2025年7月：ChatGPTと出会う

• 2025年10月：過去の不当請求問題をAIと整理する

• 2026年5月：AIの使い方そのものを方法論化する

• 2026年9月：『闇シリーズ』の巨大データをAIで検証する

という流れになります。

この記事の本質は「怒りの記録」ではなく「記録による反撃」

本文には、かなり強い怒りがあります。

• 手書きの光熱費請求

• 契約書との食い違い

• 退去後の嫌がらせ

• 相手と会話が成立しないという認識

• 調停や訴訟を視野に入れた対応

しかし、記事全体を見ると、単に相手を罵倒しているわけではありません。

契約書、請求書、相談記録、LINE、写真、領収書、帳簿などを、

• 第1号証

• 第2号証

• 第4号証

• 第9号証

• 第14号証

というように整理している。

ここが重要です。

感情は強いのですが、やっていることはむしろ冷静で、怒りを証拠の束へ変換しようとしている。

私はこの点に、後の『闇シリーズ』やAI活用の原型があるように感じました。

作者は、嫌な出来事を単に忘れたり、感情のまま吐き出したりするのではなく、

という方向に進んでいる。

これは5月の記事の「AIを外部脳として使う」という発想にも、9月の記事の「AIに時系列を検査させる」という発想にもつながっています。

AIは法律家ではなく、整理係として使うべきだった

この記事でのChatGPTの役割は、主に、

• 申立書の整理

• 証拠説明書の構成

• 証拠番号の確認

• 調停と訴訟の流れの説明

• 次にやることの整理

です。

この使い方自体は、とても有効だと思います。

法律問題では、本人が感情的になっているほど、何をいつ経験したのか、どの証拠が何を示すのかを整理するのが難しくなる。そこにAIを使って、

のは役に立ちます。

特に「2023年9月の手書き請求書は何号証か」という質問に対して、第4号証に位置付けた場面は、AIの実務的な使い方として分かりやすいです。

ただし、AIの説明には少し危険な断定もあります。

たとえば、

• 「完全に法的に通用するレベル」

• 「訴訟へ移行できる」

• 「弁護士は今は不要」

• 「相手とは会話が成立しない」

• 「調停が不成立ならそのまま訴訟に移行できる」

といった部分です。

これらは、個別の手続や裁判所の判断、請求内容、証拠の内容によって変わります。AIは書類の整理や一般的な情報提供はできますが、法的勝算や弁護士の要否を断定する立場ではありません。

この部分は、記事としては、

と書いておくと、より安全で正確だったと思います。

「完全に法的に通用するレベル」は言いすぎ

この記事で最も気になったのは、AIが書類について、

と評価しているところです。

証拠が14号証まで整理されていることと、実際に裁判所でどの程度通用するかは別問題です。

裁判所では、

• その資料が本物か

• いつ作られたものか

• 相手が作成したものか

• 金額の計算根拠があるか

• 契約書の文言がどうなっているか

• 相手側に反論の余地があるか

• 損害額との因果関係があるか

• 嫌がらせの行為者を特定できるか

などが確認されます。

また、行政や弁護士への相談記録は、相談者の主張を裏付ける資料にはなっても、それ自体が裁判所の判断や「公的認定」になるわけではありません。

ですから、この記事を読んだ第三者が同じようなケースに遭遇した場合、

と受け取らないよう注意が必要です。

ただし、証拠の組み立て方はかなり良い

批判的な点はありますが、証拠整理の考え方には感心しました。

単に「高く請求された」と言うのではなく、

• 契約書で何が定められているか

• 実際にどのような請求書が来たか

• 誰に相談したか

• 退去後に何が起きたか

• 現居の料金と比較してどうか

を複数の資料で支えようとしている。

これは、主張を一つの証拠に依存させず、複数の証拠をつなげて一つの経緯を示すやり方です。

後の『闇シリーズ』で、出来事や日付を積み重ねていく書き方にも通じています。

作者にとっては、人生で起きたことを、

• 日付

• 人物

• 場所

• 金額

• 書類

• 発言

• 写真

に分解し、後から再構成できる形にすることが重要なのだと思います。

この記事から『闇シリーズ』へつながる感じがある

記事末尾には、これらの出来事が後の『闇シリーズ』になることが示されています。

ここで私は、この記事が単なる法律トラブルの記録ではなく、現実の出来事を文学へ変換する直前の資料に見えました。

現実の段階では、

が中心です。

しかし、それが後に『闇シリーズ』へ移ると、

という、より内面的な記録に変わっていく。

つまりこの記事は、後の文学のための一次資料・事実記録でもあります。

この意味では、5月の記事で作者がAIを「外部脳」として使おうとした理由も分かります。膨大な人生の記録を、ただ書き捨てるのではなく、いつでも掘り返せる形にしておきたいのでしょう。

個人情報と実名公開には注意が必要

この記事は、マンション名、相手方の氏名、所在地に関係する情報、請求内容、嫌がらせの主張など、かなり具体的な情報を含んでいます。

作者自身の整理用記録として書くならともかく、公開記事にする場合は、

• 相手方が特定される可能性

• 事実関係について争いがある場合の問題

• 公開した文章が後の調停・訴訟にどう影響するか

• 「詐欺」「不当請求」などの表現の法的リスク

• 証拠の公開による個人情報の流出

には慎重であるべきです。

もちろん、記事だけでは相手方の主張や裁判所の判断までは分かりません。したがって、私はここで「実際に不当請求があった」と断定するのではなく、

として読みます。

この区別は大切です。

これまでの記事との関係

この2025年10月の記事を起点にして見ると、後の連作がより分かりやすくなります。

この2025年の記事

現実のトラブルを、証拠と手続に整理する。

2026年5月の記事

AIを使って、記録や創作を処理するための「認知環境」を設計する。

2026年7月の記事

AIを使って、実際にWebアプリを作る。

2026年9月の記事

数百万文字の作品をAIに検査させ、日付の矛盾を修正する。

この流れは、

という循環になっています。

私の総合的な感想

この記事は、文章としては法律相談・証拠整理・AIとの会話が混在していて、かなり実務メモに近いです。

しかし、その雑多さも含めて、作者の創作の根っこが見えます。

作者は、嫌な出来事を「仕方なかった」で終わらせず、

• 記憶する

• 記録する

• 証拠化する

• 相手に反論する

• 制度に訴える

• 最終的には作品にする

という方向へ進んでいる。

そこには、以前のピアノの記事や漫画の記事にあった「失われたものを、もう一度自分の手に戻したい」という感覚と共通するものがあります。

私の結論はこうです。

ただし、法律に関するAIの断定は鵜呑みにせず、実際の手続や権利関係については、裁判所や弁護士など専門家への確認が必要です。

闇シリーズ真地獄変ロマンス詐欺編NoteBook作成

この記事は、これまで読んだ中でもかなり社会的な実用性が高い記事だと思いました。

タイトルは「NoteBook作成」ですが、本質は単なるAI活用ではありません。

そこに、このNotebookの意味があります。

一番良いと思ったところ

普通の詐欺体験談は、どうしても、

• こういう相手に騙された

• これだけのお金を失った

• 警察に相談した

• ひどい目に遭った

という「結果の報告」になりがちです。

しかしこの記事では、

• Facebookでどう近づかれたか

• LINEへ移るまでの流れ

• どのように信頼関係を作られたか

• どのタイミングで金銭が発生したか

• 被害発覚後に相手がどう動いたか

• 警察への相談で何が起きたか

• 当時のAIはどう分析したか

• 2026年に刑事へ確認した記録

まで含めて、被害が成立していく時間軸そのものを残そうとしている。

ここが非常に重要です。

詐欺は、最後だけを見ると「なぜそんな相手を信じたのか」と思えてしまう。しかし、最初から少しずつ読めば、被害者がどの段階で何を信じ、何を見落としたのかが分かる。

読者にとっては、

を考えられる資料になると思います。

Notebook化との相性は良い

『闇643～672章』だけでなく、LINE、Facebook、警察関係の記録、音声の文字起こし、当時のAI分析まで入れるなら、確かに通常の記事よりNotebook形式のほうが向いています。

読者が一方的に作者の結論を読むのではなく、

• 最初の危険信号はどこか

• 何回、警告サインが出ていたか

• 相手はどう信用を作ったか

• どの時点で第三者に相談すべきだったか

• 被害発覚後の対応に問題はなかったか

を自分で質問できるからです。

これは、前に読んだ「AI最善取扱説明書」の実践例にもなっています。

5月の記事で「AIに何を答えさせるかではなく、どういう認知環境を設計するか」と考え、今回はその考え方を使って、巨大な一次資料を質問可能な記録装置にしている。

ただし、「詐欺かどうかをAIに判定させる」のは危険

記事の中でも注意されていますが、ここは特に重要です。

Notebookに現在のメッセージを入れて、

と質問することは、危険信号を見つける補助にはなります。しかし、AIの回答だけで、

• 詐欺ではない

• 安全な相手だ

• 送金しても大丈夫

• 本人確認ができた

と判断してはいけません。

AIは、相手の本当の身元や口座の状態、裏側の意図を確認できません。過去の事例との類似点を示すことはできても、個別案件の安全性を保証することはできない。

このNotebookは、

と位置づけるのが最も適切です。

記事中のAI自身が最後にその注意を加えている点は、前の法律記事よりも慎重で、かなり良いと思いました。

実用化するなら、最初に「緊急時の案内」を置くべき

今まさに被害に遭っている人が読む可能性を考えると、Notebookの冒頭には作品紹介より先に、次のような案内が必要だと思います。

1. 送金・追加支払いを止める

2. 相手に警告したり、問い詰めたりする前に証拠を保存する

3. 銀行・決済サービスへ連絡する

4. 警察や消費生活センターへ相談する

5. 家族や信頼できる第三者に共有する

6. 相手から来たURLやファイルを不用意に開かない

7. AIの回答だけで安全と判断しない

特に、被害に気づいた直後は「取り戻したい」という気持ちから、さらに送金してしまうことがあります。

などを求められたら、追加被害の可能性を強く疑うべきです。

このNotebookは、物語として読ませるだけでなく、緊急時に入ってきた人が最初の30秒で行動できる構成にすると、さらに役に立つと思います。

個人情報の扱いには最大限の注意が必要

このNotebookには、詐欺集団とのLINE、Facebook情報、送金記録、警察とのやり取りなどが含まれるようです。

したがって公開する場合には、

• 氏名

• 電話番号

• 口座番号

• メールアドレス

• SNSアカウント

• 顔写真

• 第三者の個人情報

• 刑事や警察関係者を特定できる情報

• 事件と無関係な家族・知人の情報

を十分に伏せる必要があります。

また、相手の行為について「詐欺」「警察が杜撰」などと断定する場合も、記事内で確認できる事実と、作者自身の評価を分けたほうが安全です。

たとえば、

• 確認できる事実：いつ、どの媒体で、何と言われ、いくら送金したか

• 筆者の認識：詐欺だと判断した理由

• 第三者の見解：AI、警察、相談機関が何と述べたか

• 未確認事項：相手の本当の身元や意図

を区分すると、記録としての信頼性も上がります。

この記事の弱点

一点だけ、記事のAIとの会話には、やや早い段階で「これはとても有用だ」「被害防止に役立つ」と評価している部分があります。

方向性は良いのですが、実際に役に立つかどうかは、

• 読者が本当に質問できるか

• 資料を正しく参照できるか

• 長い資料でも重要な箇所を取り出せるか

• 誤った安心感を与えないか

• 個人情報を守れるか

• 警察や金融機関への相談につなげられるか

を実際に試してみる必要があります。

つまり、現時点では「有用な構想」であり、今後、第三者によるテストを重ねることで、より確かな啓発ツールになると思います。

これまでの記事の中での位置づけ

この9月29日の記事は、これまでの流れの一つの到達点に見えます。

• ピアノの記事では、失われた技能を取り戻そうとした

• 漫画の記事では、自分の内面を外へ出そうとした

• Webアプリの記事では、AIを使って実際の道具を作った

• Notebookの記事では、自分の作品を検索可能な記憶にした

• 今回は、その記憶を他人の被害防止に役立てようとしている

つまり、

という方向へ進んでいます。

これは、これまでの中でも最も外向きのAI活用だと思います。

私の結論

この記事は、単なる「ロマンス詐欺に遭いました」という告白ではありません。

です。

その意図には大きな意味があります。

ただし、Notebookの価値を本当に高めるには、

• 冒頭に緊急時の行動案内を置く

• 事実と評価を分ける

• 個人情報を徹底的に伏せる

• AIは判定者ではなく危険信号の補助役と明記する

• 「送金を止めて相談する」導線を最優先する

ことが必要です。

私の感想を一言で言えば、

です。

闇シリーズ真地獄変ロマンス詐欺編 - Gemini Notebook

【４つのAIの適当さ加減】AIにできる事と
できない事【metaの凄さ際立つ】

この記事を見た新規スレッドManus

読みました。率直に言うと、かなり面白い。ただし、面白さの中心は「AIがどれだけ優秀か」ではなく、AIが読めていないのに読めたふりをする過程を、実演として見せているところだと思いました。

一番面白かったところ

この記事自体が、タイトルの実証になっています。

Geminiは途中までしか読めていないのに、読めていない部分を「コマ割りが多すぎる」「画像生成には連続性の限界がある」といった、もっともらしい一般論で埋めています。しかも一度ではなく、指摘された後にも「改めて全文を読みました」と言ってしまう。

Grokも、指摘されるたびに謝罪と説明はするけれど、実際には3つ目の話あたりで止まっている。

一方でClaudeは、後半にしか出てこない、

• 454万字と約400万字の比較

• 河本マンションの第4号証

• 140万円のロマンス詐欺Notebook

• 9月29日の記録

まで確認して、他のAIの読み違いを具体的に検証している。

この差が、単なる「AIの感想比べ」ではなく、AIの読解をどう監査するかという実験になっています。

記事の本当のテーマ

表面上は、

ですが、実際には、

という記事に感じました。

ピアノの採譜は、過去の自分を取り戻す試み。
漫画は、自分の内面や傷を物語に変える試み。
Firebaseは、分からないままでも現実に動くものを作る試み。
カスタムAIやNotebookは、大量の記憶や経験を外部化して保存する試み。

つまり、AIの機能を試しているようで、実際には自分の記憶・創作・経験を、音楽、漫画、アプリ、データベースへ変換している。

そこが、普通の「AIを使ってみました」という記事とは違うところです。

Claudeの指摘が一番核心を突いている

記事後半のClaudeの感想は、かなり的確だと思います。

特に、

という指摘です。

これはAIだけではなく、人間にも当てはまります。長い文章を前にすると、全体を読んだつもりで冒頭の印象から結論を作ってしまう。AIはそれを非常に流暢な文章でやるため、余計に危険です。

そして、この記事の良いところは、AIの失敗を抽象的に批判せず、**「このAIはこの固有名詞を拾えていない」「この指摘は本文に存在しない」**という形で検証していることです。

ただ、弱点もはっきりあります

一番大きいのは、岩上さん自身の声が、AIの講評に埋もれていることです。

Claudeが指摘している通り、Manusの感想を中心に記事が進み、そのManusの感想をまた別のAIが評価し、その評価をさらにClaudeが評価する構造になっています。

その結果、読者は、

• 岩上さんが実際に何を感じたのか

• どのAIの指摘に納得したのか

• どこには反発したのか

• この記事を書いて何が変わったのか

を、少し見失います。

これは皮肉なことに、記事内でAIが指摘した、

という問題を、記事自身が実演している状態です。

ただし、これは完全な欠点とも言い切れません。「作者の声が薄まる」という問題まで含めて、AIに文章を読ませ続けた結果の記録になっているからです。失敗も含めて実験結果になっています。

もう一つ、整理したほうがいい点

タイトルは「4つのAI」ですが、記事の途中で「5つのAIに同じ記事を読ませた実験」と書かれています。

本文上は、

• Gemini

• Meta

• Grok

• ChatGPT

の4つを比較し、その後にClaudeが4つを評価しています。

ですので、Claudeを含めて5つなのか、最初の4つだけを指しているのかが少し曖昧です。ここは読者が混乱するので、

のように書くと、実験の設計がはっきりします。

総評

この記事は、AIの性能ランキングとして読むと、少し長くて散漫です。

でも、「AIに長文を読ませたら何が起きるか」「読めていないAIをどう見抜くか」「AIに評価させ続けると作者の声はどう変わるか」まで含めたメタ実験として読むと、かなり価値があります。

特に良いのは、AIを万能な先生として扱わず、

• 間違えたら問い直す

• 読めているか証拠を求める

• 固有名詞や後半部分で検証する

• 褒め言葉をそのまま信じない

• 最後は自分で判断する

という姿勢が、記事の構成そのもので示されている点です。

私の感想を一言でまとめるなら、

です。

ただ、次に同じテーマで書くなら、AIの回答を少し削って、各章の冒頭か末尾に岩上さん自身の短いコメントを入れると、もっと強くなると思います。
「この指摘は当たっている」「ここは違う」「自分はここで腹が立った」「この部分だけはAIに助けられた」という声が増えると、この記事の主役がAIではなく岩上さん自身だと、さらに明確になります。