フィルターバブルは本当に「悪」なのか? — 人類のハードウェアとAIエージェント時代の処方箋

フィルターバブルとエコーチェンバー、似てるけど違う話

最近やたらと耳にする「フィルターバブル」と「エコーチェンバー」。似たような文脈で使われるけど、ちょっと違う。エコーチェンバーは同じ意見の人たちが集まって声を反響させ合う現象。フィルターバブルはアルゴリズムが「あなたの好きそうな情報」だけを選んで見せてくる仕組みのこと。今回はフィルターバブルの方に注目して書いてみたい。

2026年2月の衆院選で自民が316議席を取って、リベラル側に衝撃が走った。「なんでこんな結果に?」「国民は騙されてる」みたいな反応が噴出したんだけど、これって典型的なフィルターバブルの帰結だと思う。バブルの中では「高市政権は失敗だらけ」「国民は怒っている」という情報が循環していて、それが現実だと思い込んでいた。蓋を開けたら316議席。あのショックの大きさ自体が、バブルの厚さを物語っている。

でもね、ここで「だからフィルターバブルは悪だ、壊せ」と言い切るのは、ちょっと待ってほしい。

なぜフィルターバブルは存在するのか — 人類というハードウェアの話

人間の脳って、アフリカのサバンナで20〜30人の群れで暮らしていた頃のハードウェアのまんまなんだよね。ダンバー数って言って、安定した社会関係を維持できるのが150人程度。実際の生活単位はもっと少なくて、20〜30人がせいぜい。その規模なら全員の顔がわかるし、意見が違っても「まああいつはああいう奴だから」で済ませられた。

それが今、SNSで数万、数十万の「意見」が一気に流れ込んでくる。顔も名前も文脈もわからない人たちから。これ、脳の設計仕様を完全に超えてるんだよ。

だからフィルターバブルが自然発生するのは、防衛本能として当然のことだと思う。処理しきれない情報を遮断して、自分が理解できる規模のコミュニティに絞り込む。これは故障じゃない。正常な動作だ。

それを許さないネットの時代と社会

問題は、社会の方がその本能的な規模では回らないということ。

民主主義って、自分と全く違う背景の人間と同じ制度を共有するという、進化的にはかなり不自然なことを要求してくる。1億人が一つの政治体制の下で共存するなんて、ご先祖様の脳は想定していない。

さらにSNSの常時接続環境では、気合が入ってないときでも勝手に反対側の極端な意見が流れてくる。自分のコンディションに関係なく殴られる。フィルターバブルの問題って「情報が偏ること」だけじゃなくて、「バブルの外の情報に触れるタイミングを自分でコントロールできない」ことも含めてのものなんだと思う。

バブルに閉じこもれば社会が分断される。かといってバブルを壊したら本能が耐えられない。なかなかに厄介な矛盾だ。

たまに外の「毒」を取り入れる — ただし準備が必要

じゃあどうするか。完全にバブルの外に出る必要はないと思う。というか、それは危険ですらある。

政治的な立場って、単なる意見の集合じゃなくて、その人の世界観や価値観、もっと言えば「自分は何者か」というアイデンティティに直結している。バブルの外に出るということは、自分の世界観を根本から揺さぶられる体験になりうる。心理的な安全基盤がない状態で「お前の信じてたこと全部間違ってたよ」と突きつけられたら、壊れる人が出てもおかしくない。

だから「たまにちょっと外を見に行く」くらいがちょうどいい。「あっち側から見るとこう見えるのか」を少しだけ覗いて、自分の足場に戻ってくる。

ただしこれも、ある程度以上モチベーションがあって気合が入っているときじゃないと危ない。疲れてるときとか精神的に余裕がないときにやると、冷静に処理できなくて、感情的に反発するか逆に飲み込まれるかのどちらかになる。どっちにしても良い結果にならない。

要するに、バブルの外の情報は「毒」に近い。適量を、体力のあるときに、意識的に摂取するから薬になる。浴びせられたらダメージにしかならない。

AI時代の処方箋 — 秘書AIによる「事務レベル協議」

ここで、せっかくのAI時代なんだから何かいい手はないかと考えてみたい。

外交の世界には「事務レベル協議」というものがある。首脳同士がいきなりぶつかると感情的になって壊れるから、事前に事務方が論点を整理して、落としどころの候補を作っておく。それと同じことを、AIが個人のためにやってくれるとしたらどうだろう。

例えばこんなイメージだ。

反対側の意見に生身で触れるとダメージがある。でも秘書AIが「あちら側の主要な論点はこの3つで、うち1つはあなたの立場と実は共通点がある」みたいに整理してくれれば、感情的な防衛反応を起こさずに中身を検討できる。致命的な衝突を避けるためのエアバッグとしてのAI。あくまでも「下ごしらえ」であって、最終的な判断は人間がやる。ここが大事で、AIが全部整理して「はいこれが正解です」と出してしまったら、人間の思考力そのものが衰える。筋トレと同じで、負荷がないと能力は退化するから。

もちろん「AIに支配されてる」問題は出てくる。AI自身のバイアスをどうするのかという話もある。でもたぶん解決策は「完全に中立なAIを一つ作る」ではなくて、AI自身が「自分はこういう前提で整理しました、別の前提だとこう見えます」と透明性を持って提示する方向だろう。この世界に絶対座標はない。お互いの偏りの相対的な位置を把握してから話を始めるのが、現実的な出発点だと思う。

AIエージェントの時代がそこまで来ている

実はこの「秘書AI」の構想、もう現実に近づいてきている。

AnthropicのClaude Cowork、MicrosoftのCopilot Agents、GoogleのProject Mariner、OpenAIのOperatorなど、AIエージェントサービスが次々と登場している。今はまだファイル管理やタスク処理が中心だけど、これらが発展していった先に「認知的な中間層」としてのAIが来るのは自然な流れだと思う。

情報の下ごしらえをして、致命的な衝突にはエアバッグとして機能し、でも最終判断は人間に委ねる。そういうAIエージェントが一人一人に付く時代。

人類のハードウェアが処理できない規模の情報と多様性に対処するために、何らかの「認知的な中間層」は必要になる。それがAIエージェントという形で実現するなら、フィルターバブルの問題にも一筋の光が差すかもしれない。

もっとも、そのAIエージェント同士が事務レベル協議をして、それでも折り合いがつかなかったらどうなるんだっていう問題は残るけどね。まあそれは、また次の話ということで。

脳みそは積み替えられない――だからAIに底上げしてもらうという選択

AIによる実装支援が当たり前になり、簡単なコードであれば、実装からテスト、結合までをAIの中だけで完結できる場面が増えてきた。体感的には、プログラムを「書く」という作業そのものにかかる時間は、以前の10分の1、場合によっては100分の1にまで圧縮されつつあるように思う。一方で、人間側の処理速度はほとんど変わっていない。脳みそは積み替えられない以上、ここにギャップが生じるのは当然だ。

結果として、いま目立ち始めているのが「人間がボトルネックになる」現象だ。コードは一瞬で出てくるのに、それを読む、レビューする、理解するところで詰まる。Vibe Coding初期にも似た話はあったが、最近はモデルの性能向上によって、この問題がより顕在化してきた印象がある。

そこで一案として考えられるのが、AIにプレゼンテーション用のスライドを作らせるというやり方だ。コードそのものを全部追うのではなく、「何を作ったのか」「どこを変更したのか」「どこが危険そうか」をスライドという形で要約してもらう。そこから人間が質問を投げたり、特定の部分だけ掘り下げたスライドを追加で作らせたりすれば、ソースを最初から最後まで読むよりも、実用上は十分にカバーできるのではないかと思う。

確かに、AIに説明されるという構図は屈辱的に感じる人もいるかもしれない。しかし、これは人間の価値を下げる話ではなく、判断や設計といった本来人間が担うべき部分に集中するための底上げだ。同じことは実装だけでなく、設計書をAIに書かせる場合にも言える。叩き台を作らせ、違和感のあるところだけ人間が詰める方が、タイパとしては合理的だ。

私は個人で動いており、扱っているプログラムもそれなりの規模だが、それでも全体を把握し続けるのは徐々に厳しくなってきている。チーム開発であればなおさらだろう。AIが強くなり続ける一方で、人間の限界が変わらない以上、こうしたやり方は案外、悪くない手なのではないかと思っている。

書くことがない日なのか?いやある(反語)

気がついたら夕方になっていた。

昨日は夕方になってからClaudeCodeの改造をした。昨日の日記に書いた通り、Status Lineと記憶関係の変更である。serenaはデータを確認したところ、私のProjectでは活用されていないと判明。削る方向で決定し実装した。

Status Lineを利用することにより、運用が勘頼りではなく、数字を見ながらsaveをしたり、セッションを切り替えたりということができるようになった。どういう動作でコンテキストを使っていくのかがいまいちまだわかってないので、ギリギリを攻めることはできないのだが、残り数%になってからやきもきせずに済むようになったので精神衛生上、非常に良い感じだ。

プログラムで疲れたら少し創作の書き物をしてみる。あまりいいものにならない。ちょっと残念である。クロードの評価も少し辛め。

今日、土曜日になってからはプログラムを触っていない。創作もしていない。採点とか成績処理の準備をしたりとか、そんなんばっかりである。非常にめんどくさい。気が重い。

Excelで処理をしていくのだが、そこで面白かったのは、Excelに載ったClaudのプラグインである。大まかな指示を伝えると式を作ってくれる。自分の理解が怪しいところでは具体例で、「こことここをこうしたらこうしてくれ」みたいな風に頼むとちゃんとやってくれた。気が重い処理も簡単に作ってくれて非常に心のストレスが解消された。

と、こんなわけで、昨日から今日何にも書くことがない、日記に書くことがないと思っていたのだが、実際に書いてみると、わちゃわちゃと書くことはあったようだ。

案外そんなもんである。

Opus4.6とClaudeCode運用戦略

今朝未明、Claude Opus 4.6がリリースされた。Sonnet 5リークとはなんだったのか。まあいい。Opus 4.6に対応しよう。

詳しい数値とかは有識者の方にお任せするとして、こちらに関係するものだけ。
注目していた1MコンテキストウィンドウはベータかつAPI直接のみで、Claude Codeからは使えない。200K固定のまま。かなり残念。一方でDev Agents(Agent Teams)やSubagentのメモリ機能は面白い。Subagentにmemoryフィールドを持たせ、MEMORY.md作る。これでセッション横断の秘伝のタレができる。使いこなさないとありがたみはわからないだろうけど、ワクワクする。

大雑把に機能確認をしたところで、LAM( https://github.com/sougetuOte/LivingArchitectModel )のメモリ戦略を見直した。

最近問題としているのは圧縮処理だ。残りが少なくなってるのを認識した時点でセーブ処理を行い、セッションの切り替えをするのだが。SerenaとDailyコマンドを併用し、コンテキストの約7-8%を消費している。200Kの8%は16Kトークン。これは痛い。また、serenaはCLAUDE.mdで明示的に指示しないと、grepで済ませてしまう傾向があるらしい。セーブ処理でトークンを消費しても、セッション時にはあまり使われていない可能性がある。私のプロジェクト規模(個人開発、全体像が頭に入る程度)では、Serenaの恩恵自体が薄いのかもしれない。

serenaを常駐させるだけでコンテキストを圧迫するので、対策を考える。まずは、セッションのセーブ処理だけを目的とした軽量な/quick-save(SESSION_STATE.mdのみ、3-4%)と、フルセーブ(SESSION_STATE.md + git commit & push + dailyコマンド)に分離する方針を立てた。作業セッションのコンテキストを開発に全振りするという考え方。StatusLineでコンテキスト残量を常時監視しつつ、残り15-20%を切ったらquick-saveでセッションをexitする。クイックセーブについては恐らく10%程度から実行すれば十分だと思うが。そうすれば、auto-compactに怯えなくて済む。serenaの常駐を止めればコンテキストを運用に使える量が増える。より余裕を持って使えるようになるだろう。

まだ机上の空論だが、固い戦略だと思うので恐らく外すことはなかろう。まずは、StatusLine導入から実際に試していく。

プログラミング教育のAI時代への転換 ―『書く技術』から『導く設計』へ―

ソフトウェアの作成がAIツールによってソースコードの作成からアーキテクト、マネージメントに移りつつ有る。
それに伴い現在のプログラミング初等教育は、ある種の岐路に立たされていると感じる。初学者が学ぶ「低レイヤーな基礎」と、実務で行う「AIを動かすための高レイヤーな設計」。この乖離を埋める鍵は、開発における「ガードレール」の捉え方にあるのではないか。

これからの教育は、これまでと違うアプローチが必要だ。第一段階では、AIツールベンダーが用意しているガードレールを活用し、プログラム作成の成功体験を与える。バイブコーディングの波に乗り、まずはとにかく完成品を積み上げること。この成功体験を通じて、ソフトウェアの作成の全体像を体感させる。これは、今までの初心者教育には出来なかったことだ。これだけでもこれまでの教育方法を刷新する価値がある。
そのうえで、標準の与えられたガードレールでは不足が生じた段階になれば、ガードレール(設計図)を自ら設計する必要性を気づかせる。

自分でガードレールを引くためには、結局のところ、コンピュータがどう動くかという基礎的な理解が欠かせない。C言語やPythonの初歩を教える意味は、実装力を養うためではなく、AIに与える指示の妥当性を判断し、構造を破綻させないための「鑑識眼」を養うことに集約される。教育を否定するのではなく、出口を「設計」へとシフトさせる。それが私の考える、新しい時代の初等教育の姿だ。

では、書けない技術者についてどう考えるのか。これは作成のレイヤーが変わったと捉えるしかないのだろう。我々だってアセンブラは書けないのだから。

バイブコーディングのその先で

おはようございます。

結局、Claude Sonnet5は来ませんでしたね。夜中に起きた時にチェックしてみたんですが、Xのトレンドに上がってなくてがっかりしました。

昨日は年度末特有のドタバタでした。プログラムについてはほんの少ししか触ることができず、残念でした。

私はClaudeCodeを使ってプログラムを作成していますが、自分のプロジェクトに限って言えば、ここ数ヶ月まともにソースコードを見たことすらありません。LAMによるガードレールを作り、テスト計画を立て、リファクタリングや実際の使用してのユーザーテストなどをやることで、片がついてしまうからです。細かいところの最適化についてはいろいろあるんでしょうけれども、使用していての問題は特にありません。

私の場合は計画を立てたり構造を考えたりするのは好きなんですが、コーディング能力というといまいちです。なので、私の場合バイブコーディングを行うのがかなり性に合っています。今やバイブコーディングというより、何なんですかね、このプロジェクトの作り方は。実際全然コーディングしてないので、これはプロダクトと言うべきなのか何なのか。

この作り方が標準的になってくるのであれば、現在よりもコーディングの職人的なところが排除されていき、工芸品より工業的になっていくのではないかと思います。大規模なプロジェクトについては作り方は知らないのですが、中規模・小規模となってくると、どうしてもメンバーの俗人性というのが反映されてしまいます。設計や指示の仕方などを統一していけば、ClaudeCodeなどのツールが一定の水準で物を作り込んでくれる。そういう風になるのではないかなと考えています。

Sonnet5の噂とLAMの更新

昨日2月2日、AnthropicのClaude Sonnet 5リリースのリークが出た。そのリークを信じるのであれば、明日未明、2月4日未明にリリースされるはずだ。様々なアップデートが、その中にサブエージェントなどにチームを組ませるという項目があった。嬉しい反面、気になるところが出てくる。

私が現在利用している自作ソフトに「LivingArchitectModel」というものがある。これは一言で言うなら「Claude Code のための行動規範フレームワーク」だ。cc-sddやspec-kitみたいなもんだと思ってもらえば良い。今作っているソフトはこの LivingArchitectModel をテンプレートとして作っている。

そして現在ちょうどこのLAMについて大規模なアップデートをしようと考えていた。何かというとサブエージェントのチーム化だ。つまり、このリーク記事のSonnet5としっかり被ってしまうというわけだ。先日、ClaudeOpusの4.5に、「agent swarm」の記述があったという話も記憶に新しい。なんにせよ、エージェントのチーム化というのはホットなキーワードである。

私のような一般人が作るより、Anthropicの最高の技術者たちが作った方がいいに決まっているし、標準化されているものを使うのはいいテクニックだ。私はしばらく待つことにした。

ネット上のアナリストによると、Opusが出てまだ10週間しか経っていない。Anthropicがここで新しいモデルを出すのは彼らのやり方に合わないという。確かにそれはある。ただ、それは周囲の状況を見て考えるとそうでないかもしれないと言える。

Gemini3Proが出てからのOpenAIの動きを考えてみてほしい。レッドアラートが出て、そしてすぐに5.2が発表された。それからもGoogleはGeminiを様々なサービスと組み合わせようとしている。Google ChromeとGeminiの一体化というのもまた一つある。そこでnano bananaが使えるというのは恐ろしい話だ。

そういう状況を考えると、Anthropicが彼らのやり方を破る可能性は十分にある。swarmにしても今回のリークにしてもそのマーケティングに当たるものかもしれない。

まあ何にせよ、私にできることはほんの少し待つだけだ。

焦る日々

早いものでもう2月である。

私は単年度契約の講師がメインの収入なのであるが、来年度はかなり授業が減りそうなのである。ここ数年はほぼ講師の収入に頼っていたため、非常に不安を覚えている。

性格的に営業ができる人間ではない。どうしたらよいかAIに相談などもしてみるのだが、これといったいい手が見つからない。

その中にはudemyやココナラなどで講師としての腕を使い、動画などを公開してはどうかというのもあった。なかなか気が進まないのがこれも一つの手段として考えておくべきだろう。

もう一つ考えているソフトウェアの作成。AIを使っていろんな人がより簡単にソフトウェアを作ることができるようになったが、一定以上の完成度を保つためには、やはりプログラミングの知識、広範な設計の知識が必要だ。一応自分も講師以外でもいくらか普通のプログラムを作ったことがある。それで何かできないかと考えているのがもう一つだ。

例年2月3月4月は授業がないため耐える時期なのであるが、なんとかしてこの間にものになるものを一つでも作っておきたい。月に2、3万でもだいぶ違う。3、4万、できれば5万などと、取らぬ狸の皮算用を考えているのだが、果たしてどうなるやら。

ComfyUIでひどい目に有った話

今朝はいつもより早く起きたので、ちょっとお絵かきでもしてみるかということで、ComfyUIを立ち上げた。私のお絵かきはAIと自分で描くのを混ぜ混ぜしているので、ComfyUIが必要なんだ。

で、まあ、ターミナルを見ていると、いつも気になるエラーというかワーニングがあって、これどうにかならんかなと思った。あともう一つ、Xformsというライブラリを入れられないかなと思った。じゃあ修正してみようか。これがいけなかった。

ChatGPTとお話ししながらやっていき、おおよそうまくいった。それでもまあ3時間ぐらいはかかったのかな。で、最後に開発してた環境とこれまで使っていた環境を入れ替えてみる。そうすると、なんということでしょう。全然動かない。何が悪いかも最初わからず、あたふたあたふたとする。やっているうちにだんだんと話がややこしくなっている気がするなぁとなった。集中力も落ちている気がする。

これはAIと作業を進めるときのまずいパターン。AIは一つのことに集中するあまり視野が狭くなる。どう見ても無理筋なことをどんどんどんどん詰めていくので、環境調整なんかの場合はかえってまずいことになったりする。今回はそれだ。

見切りをつけた私はそこからもう一回新しく環境を作り直すことにした。そこまでのログがあるので、楽に進めるかなと思ったのだが、あまりにもログが長いため、ChatGPTもうまく道筋を探しきれないようだった。

まあそれでもなんとかかんとか動くようになって、気がついたらもう12時。半日完全に潰したことになる。最終的には当初見込んだワーニングは取り去ることができたし、Xformも無事動くようになったのだが、今また別の何かが出ている。これもこれまでの作業の際に取り除いた覚えはあるのだが、ChatGPTが頻繁にフリーズするようになったので、一回このスレッドを諦めることになった。

スレッドを捨ててしまえば、次の時には記憶が引き継げない。元のスレッドでまとめを作ってもらってもいいんだが、それでもやはり長くなるだろう。

今回はとりあえず自分で思ったことをメモに残し、次回やる気になったときにChatGPT、Gemini、Claudeのどれかと一緒に作業を進めようと思う。

逆向き瞑想 昼寝

今朝も昨日の日記を書こうとしたのだけれども、なかなかネタが思いつけないので、逆向き瞑想というのをすることにしてみた。

別に特別なことをするわけではない。遡りたいことをずっと考えていって、考えていって、考えていって、心を鎮める、それだけ。探しているものが見つからないときに、自分がどこを動いてどうだったっけ、みたいなのをどんどんどんどん遡って考えるのと同じようなもんだ。

まあ、今私は実際にそのネタを探そうと思っていろいろやっているので、瞑想というのとは違うのかもしれない。

そうして考えてみると、昨日は残念なことがあったのを思い出した。

外での仕事は午前中で終わったので、昼食を取って帰宅。デグーのゲント君のケージを掃除してあげて、そしてちょっと疲れたなと思って昼寝をした。これがいけなかった。2時間ほどして目が覚めた。タイマーをつけてなかった。起きたら体がすごくだるい。

結局その後、だるさ、きつさで何もしないままに晩御飯も手抜きにしてしまい、そして寝た。完全に無駄にした感。

昼寝というか、仮眠は長く取りすぎるとダメっていう話があるんだけれども、まさにそれをやってしまった感じ。

というわけで、ネタがないなぁと思って逆向き瞑想(?)を試してみたら、昨日のことを思い出したよという話でした。