00:00
えっと、現実世界の引っ越しって、本当に骨が折れますよね。
いや、本当にそうですね。あの、段ボールの山を見るだけで嫌になります。
ですよね。何とか心境に荷物を運び込んで、さあ終わったと思っても、そこからがまた大変で。
ええ。
あの、ハサミどこに入れたっけとか、Wi-Fiのルーターの設定ってどうやるんだっけとか、なんか生活の基本インフラを整えるだけでヘトヘトになっちゃうじゃないですか。
わかります。どこに何があるか、その空間のルールをゼロから自分に教え込まないといけない状態ですよね。
そうなんです。
新しい部屋にワクワクする気持ちよりも、あの、まずは今まで通りの日常を取り戻すための作業に追われてしまうというか。
まさにそれです。そしてですね、それって私たちが新しいAIツールを使い始めるときに直面していることと、全く同じなんじゃないかなって思うんですよ。
ああ、なるほど。AIの乗り換えですね。
はい。リスナーのあなたも経験があると思うんですが、AIのモデルが新しくなる度、ツールを乗り換える度に、自分がどういう仕事の進め方をするのかとか、前提条件は何か、コードを書くならタブかスペースかみたいな、あとは前回どんな致命的なミスをしたから絶対に避けてほしいアプローチは何かとかですね。
そういう細かなコンテキストですね。
ええ、それを全部真っさらなAIにゼロから説明し直すっていう、正直心が折れそうになります。
確かに、おお、新しいモデルが出たってワクワクして触り始めるのに、いざ実務に組み込もうとした瞬間に、その初期設定というか、AIのしじけ直しの壁にぶつかって手が止まっちゃうんですよね。
そうそうそうなんですよ。
これは今あらゆる現場で起きている、あの深刻な生産性のボトルネックだと言えますね。
ええ、なので今回の深掘りでは、そんな私たちのフラストレーションを劇的に解消するかもしれない、あるパラダイムシフトについて探っていきます。
はい。
ベースにするのは、2026年7月22日に公開された、ITエンジニアによるニュースレター、AIエージェント日地速報です。
今日のニュースですね。
そうです。今日のミッションは、AIを乗り換える際、仕事の記憶はどこまで連れていけるのか、という問題を徹底解剖することです。
非常にタイムリーで重要なテーマですね。
はい。最新のAIツールがどのように記憶を扱い始めているのか、そしてこれから私たちがどうAIの記憶をマネジメントしていくべきか。よし、これを紐解いていきましょう。
よろしくお願いします。このニュースレターの著者は、各AIツールが記憶という概念をどう実装しているか、実務的な視点から非常に細かく分析していますよね。
ええ、本当に詳しくて。まず私が驚いたのが、日本時間の今朝リリースされたばかりのCodex 0.145.0の目玉機能なんです。
ああ、あのインポート機能ですね。
はい。インポートというコマンド一つ叩くだけで、なんと別のAIツールであるカーソーとかクロードコードから設定、会話のセッション、さらにはMCPサーバーやプラグインまで丸ごと取り込めるようになったそうなんです。
03:10
それはすごいですよね。
しかも、プロジェクト単位の記憶まで引き継げると、これって結構衝撃的じゃないですか。
そうですね。これは単なる利便性の向上ではなくて、概念の大きなターニングポイントなんですよ。
ターニングポイントですか?
ええ、特にMCP、つまりAIが外部のツールや社内データベースに接続するための共通企画まで持ち込めるというのは非常に強力です。
ちょっと待ってくださいね。MCPって外部データとの接続企画ですよね?
はい、そうです。
それごと引き継げるってことは、ただのテキストのメモを移すのとは役が違うってことですか?
全く違います。テキストのコピペではなくて、鍵の束と道具箱をそのまま渡すようなものなんですよ。
鍵の束と道具箱、なるほど。
弦とか、GitHubの特定リポジトリにアクセスする設定とかですね、そういったAIの手足となる機能までそっくりそのまま新しいツールに移植できるんです。
ああ、状況がすごく見えてきました。
わかりやすく例えるとですね、これまでは新しいAIを使うっていうのは、新しいオフィスのまっさらな机に座らされるようなものでしたよね。
ええ、本当に何もない状態ですね。
でも今回の機能は単に新しいオフィスに机を運ぶだけじゃなくて、前の机に貼ってあった大量の付箋とか、引き出しの中の作業メモとか、さらにはどこのキャビネットの鍵かという情報まで全部そのまま持ち込めるようなものですよね。
まさにその通りです。ここで非常に興味深いのは、AIの乗り換えという行為の概念がですね、新しいチャットを開くということから、作業環境、つまり仕事場を丸ごと引っ越すことへと根本的に変わったという点なんです。
仕事場丸ごと引っ越しですか?
ただニュースレターの著者はここで非常に冷静な視点を提供しています。引っ越し業者にすべてを任せてはいけないと。
え、なんでですか?全部運んでくれるなら、とりあえず全部トラックに詰め込めばいいんじゃないですか?後で整理すればいいし。
そこが落とし穴なんですよ。引っ越し業者に荷物を渡す前に、捨てるべきゴミを選ぶのは人間でなければならないと著者を指摘しています。
ゴミですか?
ええ。例えば数ヶ月前のプロジェクトで使っていた一時的な回避策とか、今はもう使わない古い手順まで持って込んでしまったらどうなると思いますか?
ああ、なるほど。新しいAIが初日から過去の変な癖とか、時代遅れのルールを引き継いでしまうわけですね。
そうなんです。
それは嫌ですね。せっかく新しいツールなのに。
ええ。だから、著者が提案しているように、いきなりすべての案件を本番環境に取り込むんじゃなくて、まずは小さな検証用の環境でリストアップして、不要のものをそぎ落としてから持っていく。そういった記憶の棚卸しが必須になるんです。
なるほどなあ。耳が痛いですね。とりあえず全部保存しちゃうタイプなので。
06:05
でも専門家、ここでちょっとリスナーの皆さんが思っているかもしれない疑問をぶつけてもいいですか?
もちろんです。何でしょう?
AIの記憶力って、人間と違って物理的な限界がないじゃないですか。容量なんていくらでも増やせるというか。
ええ。サーバーさえあれば。
だったら、過去の案件の手順や失敗も全部そのまま大きなデータベースに覚えてさせておけばいいんじゃないですか?
データは多い方が、あの文脈を理解して賢くなるってよく言いますし。
それはですね、誰もが最初に抱く直感的な期待なんです。でも実はJITSMにおいて最も危険なアプローチの一つなんですよ。
え、危険なんですか?
はい。ソースの中でまさにその全部を覚えるアプローチを極限まで追求しているのがJenspark 6.0というツールです。
ああ、Jensparkですね。あのアプローチすごく未来的で面白いなと思って読んでました。
確かに野心的ですよね。
彼らはセカンドブレインっていう一つの巨大な記憶の器に過去のメール、文書、会議、チャットの履歴をすべて集約しているんですよね。
そうです。
さらにセカンドブレインノートっていう専用端末を使えばオフラインの会議室での音声記録すらも自動でその器に放り込める。
これって究極の自分のすべてを知っているアシスタントじゃないですか?
ええ、響きは本当に素晴らしいです。しかしですね、これを実際の業務の全体像と結びつけて考えてみましょう。
はい。
情報がすべて一つの大きな箱に入ってしまうと何が起こるか。著者はこれを文脈の汚染、コンテキストポリューションと呼んで継承ならしています。
文脈の汚染ですか。でも検索エンジンだって古い情報と新しい情報が混ざってますよね。
ええ、混ざっていますね。
AIもタイムスタンプを見て、あ、これは3年前のデータだから無視して、今日の決定事項を優先しようって賢く判断できるんじゃないですか?
そこがですね、非常に鋭いご指摘なんですが、AI、つまりLLMと単なる検索エンジンの決定的な違いなんです。
どういうことですか?
AIは情報をデータベースとして時系列で整理しているわけじゃないんですよ。プロンプトに入力された情報を一つの巨大な現在の文脈として同時に処理するんです。
えっと、つまりAIにとっては3年前の没案も今朝の決定事項も同じ今ここにある情報としてフラットに並んで見えているってことですか?
その通りです。例えばですね、あなたがマーケティングのコピーを書いていて、過去の会議でこの表現はコンプライアンス的にアウトだから絶対にやめようと却下された議事録があったとします。
はい、ありますよね、そういうの。
もしそれが同じセカンドブレインに入っていると、AIはマーケティングやコピーというキーワードに反応してですね、
その却下されたはずの危険な表現を関連性の高い有益な情報だと勘違いして、今日の提案に混ぜ飛んでしまう危険性があるんです。
09:02
うわ、それは怖いです。あの、冷やの収納をフラして何でも放り込めば片付いた気になりますけど、
いざ料理をしようとしたら、冷蔵庫の新鮮な野菜と3年前の賞味期限切れの缶詰がごちゃ混ぜに出てくるようなものですね。
まさにそのごちゃ混ぜを防ぐために全く対照的なアプローチをとっているのが、アンチグラビティ2.0なんです。
アンチグラビティ、あれは面白かったですね。
ええ、彼らのアプローチは言ってみれば意図的な記憶喪失です。
意図的な記憶喪失、えっと、それってどういうことでしたっけ?
彼は履歴やルールを現在の作業フォルダだけに厳密に結びつけて、他の案件の記憶とは絶対に何があっても混ぜないという徹底した隔離アプローチなんです。
例えば、あなたがフリーランスのエンジニアで、お堅い金融機関の顧客Aとスピード重視のスタートアップの顧客Bの案件を同時に抱えているとしますよね。
はい、よくあるシチュエーションですね。
顧客Aでは厳密なセキュリティチェックのプロセスが必須ですが、顧客Bでそれをやると遅すぎるって怒られるわけです。
ええ、文化が違いますからね。
もしAIがこの2つの記憶を共有していたら、他のプロジェクトではこうしていたので気を利かせましたなんて言って、顧客Bのゆるいルールを顧客Aに適用してしまう。そんな大事故が起きかねません。
ああ、それは致命的ですね。腑に落ちました。絶対に境界線を超えずにこのホルダーのルールだけを守るAIの方が、実務では圧倒的に予測可能で扱いやすいんですね。
ええ、実務における安心感が全く違います。
でも、そうなってくると新しい疑問が湧いてきます。
何でしょうか。
絶対に破ってほしくない絶対のルールと、今日はこういうエラーが出たみたいな日々のちょっとした記憶はどうやって整理して分割すればいいんでしょうか。一緒のファイルに書くわけにはいかないですよね。
そうですね。その疑問へのベストプラクティスとして、クロードコードとオープンクローの仕組みが非常に参考になります。
クロードコード、最近話題ですよね。
はい。クロードコードの最新版では、記憶を2つに明確に分けています。
一つは、人間が手書きで設定するプロジェクトの絶対の支持書、であるクロード.mdというファイルです。
なるほど。人間が書くファイルですね。
ええ。そしてもう一つは、クロード自身が作業の過程で自動的に書き残す自動記憶のファイルなんです。
ああ、オープンクローの方も似たアプローチですよね。
そうです。記憶をブラックボックス化せずに、すべてを普通のマークダウンファイルとして可視化しています。
どちらの詳細な記録である短期記録と、厳密に選ばれた長期記憶、メモリー.mdですね。それを分けていると。
ええ。どちらのツールも、人間が管理するルールと、AIが自律的に収集する情報を物理的というかファイルレベルで分けている点が共通しています。
なるほどなあ。ここからが本当に面白いところなんですが、これってつまり、人間が書くファイルは国の憲法で、AIが自動で書くファイルは日々の業務日誌みたいなものですよね。
12:12
憲法と業務日誌ですか?
はい。憲法には絶対に守るべき法律が書いてあって、業務日誌には日々の日付が書いてある。
憲法があるから、業務日誌の内容が多少暴走しても安心みたいな、そういう理解であってますか?
えっと、その例えは概念を理解する上では非常に面白いんですが、実はシステム的な観点からすると、一つ致命的な欠陥があるんですよ。
え、欠陥ですか?
はい。AIにとって、そのマークダウンファイルに書かれた憲法というのは、国家の絶対的な法律ではなくて、オフィスの休憩室に貼られたお企業よくしましょうっていうお願いポスターに過ぎないんです。
な、なるほど。えっと、ちょっと待ってください。どういうことですか?このファイルは絶対に削除しないでって指示をファイルに書いておけば、AIは守るんじゃないんですか?
人間なら守りますよね。でも、LLMの根幹的なメカニズムを思い出してください。彼らはあくまで、次に来る確率が高い言葉を生成しているだけの確率的テキストモデルなんです。
あー、確率で動いているから。
ええ。グールを守るという物理的な制約、つまりシステム的なロックを持っているわけではないんです。だから、どれだけ強い言葉でマークダウンに書いてあっても、確率的に別の行動が適当だと計算されれば、平気でルールを破ります。
つまり、情報としては知っているけど、物理的に違反できないわけではないと。
その通りです。
じゃあ、絶対にAIにやらせたくない操作、例えば本番データベースの削除なんかはどう防げばいいんですか?ポスターじゃ止められないなら。
そこで必要になるのが、記憶ではなくシステム的な制約です。ソースでも触れられていますが、特定のタイミングで必ず動くフックと呼ばれるプログラムの処理や、システム側のアクセス権限そのものに組み込む必要があるんです。
フックですか?
はい。ルールを読ませるのではなく、ルールを破らアクション自体を実行不可能にするわけです。
なるほど。プロンプトで長々とお願いする時代は終わりで、本気のルールはシステムで縛れと。
ええ、まさにそうです。
だからこそオープンクローは、記憶を自動整理するドリーミングという機能を初期設定でわざわざ無効化しているんですね。
ご明答です。AIに自動で記憶を書き換えさせると、いつの間にか休憩室のポスターの内容が書き換わってしまって。
はい。
AIが独自の解釈で暴走し始めるリスクがあるからです。明示的に人間が許可した時だけ長期記憶へ書き込まれる、そういう安全設計になっています。
そうなってくると、結局のところ、最終的に何を長期記憶に残すかを決めるのは、私たち人間になるということですね。
そこが、これから私たちがAIと働く上で最も重要な役割になります。そのプロセスを見事にシステム化しているのが、マナースというツールのアプローチですね。
15:00
マナースですね。終わった会話から再利用できそうな指示とかワークフローをAIが自分で見つけ出して提案してくれる。
でも、人間がその内容を見て承認するまでは、決してプロジェクトの記憶に反映されないんですよね。
はい。そこがポイントです。
私、ソースの中で著者がこの運用方法について、覚えさせる前に一晩置くくらいでちょうどいいって書いていたのに、ものすごく深くうなずいてしまったんですよ。
実体験として何か心当たりがあるんですか?
ありますよ。チャットの勢いで一時しのぎのつもりで、よし、エラーが出たらとりあえずこの処理スキップしてって指示したとするじゃないですか。
やりがちですね。
もし、AIがそれを勝手に長期記憶に入れたら、永遠にエラーを無視するヤバいAIが誕生しますよね。
確かにそれは恐ろしい。
次の日、冷静になってみたら、いや、あの時だけ特別だったな。記憶させなくてよかったってこと。本当によくあるんです。
まさにそれが人間の承認プロセスが不可欠な理由ですね。
さらに、ハームスエージェントというツールは、この記憶の仕組み自体をプラグインのように付け替えられるようになっています。
プラグインで付け替える、どういうことですか?
プロジェクトの性質に合わせて、記憶の保存先や検索方法を根底から変えられるということです。
へー。
機密さえが高いなら、自社のローカル環境にあるベクトルデートベースを使い、スピード重視なら外部のクラウドを使うといったように、記憶のインフラ自体を選べる時代に入っているんです。
AIのモデルを選ぶように、記憶のインフラまで選ばなければいけないんですね。選択肢が増えるのはいいことですが、正直私たち人間がそれをどう管理していいか途方に暮れてしまいそうです。
だからこそ、ニュースレターの著者が提唱している記憶表という実践的な解決策が非常に光るんですよ。
記憶表ですか?
はい。AIに長期記憶として何かを保存させる前に、ただのテキストではなくて、特定のメタデータを付与すべきだというアイデアです。
メタデータ、ソースによると記憶の名前、元ソース、決めた人、使って良い案件、最終確認日、消す条件、そして別のAIへ持ち出せるかの7項目ですね。
ええ。著者は、少なくとも使って良い案件と消す条件が空っぽの記憶は絶対に長期記憶にあげるべきではないと断言しています。
消す条件を最初に決めるというのはすごく新しい視点でした。プロジェクト終了時とか、新しいAPIがリリースされるまでとかですね。
そうです。現在のAIにおいて、記憶の容量不足はもはや問題ではありません。何でも記憶できます。
しかし、誰がいつ決めたのか、いつ消すべきなのかという賞味期限のメタデータがない記憶は、どれほど大量にあっても、ただの危険な探し物になり下がってしまいます。
危険な探し物。
無数にある引き出しの中から、どの情報が今の文脈にあっているのか、AI自身も迷ってしまうんです。それが結果として、ハルシネーションを引き起こす原因にもなります。
18:00
つまり、これってどういう意味なんでしょうか。リスナーのあなたにもぜひ考えてみてほしいんですが、
はい。
少し前まで、私たちはAIにどう命令するか、つまり、プロンプトエンジニアリングの呪文を覚えることに必死になっていましたよね。
ええ。みんなプロンプトのテクニックを追い求めていました。
でも、これからの私たちの仕事は、プロンプトを書くことではなくて、この記憶を採用するか、廃棄するかを判断し、適切なタグをつける、記憶の門番になるということじゃないでしょうか。
まったくその通りです。これからのAIリテラシーというのは、AIにどう出力させるかではなく、何を覚えさせ、何を忘れさせるかを設計する能力にシフトしていくでしょうね。
さて、今回の深掘りも終わりに近づいてきました。あなたに向けて、今日のポイントをまとめましょう。
はい。コーデックスのアップデートが象徴するように、AIを乗り換える際、外部ツールへのアクセス権限や仕事の記憶をごっそり持ち運べる時代がやってきました。
引っ越しが格段に楽になったわけですね。
ええ。でも、だからといって全部をインポートしてはいけません。ジェンスパークのような全てを統合するアプローチは文脈の汚染を引き起こす危険性があります。
そうでしたね。
代わりに、アンチグラビティのように隔離することや、オープンクローのように自動記憶を制限することが実務では重要になります。
不要な記憶を断捨離し、何を次のAIへ持っていくかを戦略的に選ぶ必要があるということです。
忘れないAIというのは驚くほど便利です。しかし、間違った学習や時代遅れのルールすら永遠に忘れないという恐ろしさも同居しています。
その手綱を握るためのフックや記憶表といった仕組みを理解して運用していくのはシステムではなく、私たち人間なんですよね。
そこで最後に、ソース資料から一歩踏み込んで、あなたに一つ問いを投げかけたいと思います。
何でしょう。
もしあなたが、自分の完璧な仕事の癖、過去の全ての文脈、プロジェクトの暗黙の了解まで、全てを完璧に記憶して、完全にあなたに適用したAIを作り上げたとしましょう。
はい、理想的なパートナーですね。
でも数年後、そのAIはどうなるでしょうか。もしかすると、あなた専用に数を適用しすぎて、逆に他の誰とも、他のどんな標準的なプロジェクトとも働けない、融通の効かない頑固なAIになってしまうのではないでしょうか。
ああ、それは非常に考えさせられる視点ですね。特定の企業のベンダーロックインではなくて、ユーザー自身が教え込んだ自分専用の記憶の重みそのものによって、動き回りが取れなくなる未来というか。
ええ、新しい標準システムや他のチームとのコラボレーションができなくなる。自分専用の黄金能力を自分で作ってしまうかもしれないんです。
なるほど。
オープニングで、引っ越しの段ボールの話をしましたよね。あなたが今、よかれと思ってAIの段ボールに詰め込もうとしているその記憶は、未来のあなたの身を軽くするものでしょうか。それとも、身動きを取れなくする重い足枷になってしまうのでしょうか。
21:03
深いですね。
次にAIを乗り換えるとき、その段ボール、本当に全部持っていきますか。ぜひ考えてみてください。
それでは、今回の深掘りはここまでです。お聞きいただきありがとうございました。
