トーク

皆さんもクレジットカードを使った際に、身に覚えのない決済が来て、不正に利用されてしまっていたという経験があるのではないでしょうか？
不正といっても、クレジットマスターアタック、スキミングといった外部からの攻撃、カード所有者による悪意のある決済など、多岐に渡り不正決済は年々増加しています。

本トークではカード事業者が不正を防止するために日々行っている攻撃の検知、分析、対策、評価といった一連の運用やそれらを支えるシステムの開発をどのように行っているかを技術的な文脈を元にお話しします。

具体的には以下のような内容をお話しする予定です。

• カード決済における代表的な攻撃とそのパターン検知、および対策をどうやっているか
• 不正決済を検知し防止、抑制するためのシステムをどのように構築しているか
• 不正対策を行っているチームの日常、どのようなKPIを設定して攻撃の予防や改善を行なっているか

本トークを聞くことで、皆さんのカード決済が安心に行えている一旦が垣間見れるかもしれません。

コードを読んでいると、この変数はどこで定義され、どこで値が設定されたのか？を確認することがしばしばあります。
再代入が多いとどのタイミングで値が変更されるのか？を確認するコストが発生するので、私はめんどうだと思ってしまいます。
また、再代入がないほうがメンテナンス性が高いと信じています。なぜならば、すべてが再代入なし（= すべてが定数）の方がバグが生まれにくいはずだからです。
（いわゆる関数型プログラミング、というやつです。）

と、いうことで私は基本的に再代入をしないコードを書くように心がけています。
（もちろん、それによるデメリットがあるのも承知でそのようにしています。）

私が始めたOSSではありませんが、現在は9割方私が書いたコードになっているnode-lambda ( https://github.com/motdotla/node-lambda ) （JavaScriptです）を例に、頑なに再代入をしない（関数型プログラミング）を実践した例を紹介します。
（これまではデメリットについて、厳密に検証したことがなかったのですが、改めて検証してまとめてデメリットについても発表します。）

大規模開発の参考になること間違いなし！

ここ数年、来るべきクッキーレス時代に備え、デジタルマーケティング分野に関わるエンジニア達は人知れず戦ってきました。現役の広告エンジニアである筆者もその最前線に身を投じた一人です。しかし、 2025 年 4 月、 Google は 3rd party cookie の廃止を事実上断念し、その壮大な挑戦は突如として大きな転換点を迎えます。

このトークは、その激動の渦中に生まれた Attribution Reporting API (ARA) という技術へ捧げる、筆者からの鎮魂歌です。

ARAは、プライバシーを守るという理想が生んだ、あまりにも複雑で難解な人工遺物です。しかし、その複雑さの奥には、最先端の Google エンジニア達による知恵と格闘の跡が刻まれています。このトークでは、2024 年 1 月のプロジェクト発足以来 1 年以上 Attribution Reporting API (ARA) の実装に携わった筆者が、 ARA の仕様を読み解くために必要な知識を短時間で効率よく収集することを目標に、以下のキーワードを解説します。

• Attribution Reporting API (ARA)
• registration
• attribution source/trigger
• source type event/navigation
• event-level/aggregatable&summary report
• Publishser / Advertiser / Adtech / Browser
• contribution budget
• ノイズと差分プライバシー
• Aggregation Service と TEE

AI AgentでPerlのコードを書くことはもちろんできるのですが、
プロジェクトの込み入ったコンテキストを把握してコード生成するのはまだ発展途上だと感じます。

「リポジトリを丸呑みして、コンテキストを把握してくれればいいのに…」

実際、リポジトリだけでコンテキストが完結することはないですし、丸呑みさせれば開発規模に比例してトークン量が増えて、破綻します。

そんな折、先日発表された Hono CLI のアプローチがいい感じだと思いました。
このCLIには、Honoに関する知識を検索し、必要そうな情報の詳細を確認して、できたアプリケーションをテストする機能があり、
これのおかげで必要なタイミングで必要な情報だけ取得するアプローチをAI Agentに組み込みやすくなっています。

「Perlでもほしい！」

ただ、いくつか課題があります。

課題1: 同じことをするにも複数やり方がある。

use Moose;  # え、うちMouseなんだけど...
use Path::Tiny;  # Path::Classじゃないの...？

本当は、プロジェクトで推奨している技術を空気読んで選んでほしいです。

課題2: 公式ドキュメントが過去の経緯も含め詳細な記述。

間違っていることではないですが、目の前の仕事を片付けるだけなら、もっと要点を絞ってもいいはず…!

課題3: レビューする人がPerlに詳しいとは限らない

飛躍した課題ではありますが、生成されたコードの正しさを人間が理解できた方がメンテナンスはしやすいと思います。

このLTでは、これらの課題へのアプローチを話したいと思います！

「あなたが本気で欲しいAI Agent」のLTです

Claude Codeをはじめとするコーディングエージェントは圧倒的な速さでPythonなどのコードを書きます。
ですが、生成されたPythonコードは「Pythonを理解している」とは言えません。
例えばf-string (f"Hello, {name}"のように文字列に式を埋め込める)はロギングのメッセージに使うべきではないのですが、平気で量産してきます。
私が決して書かないようなコードをコーディンエージェントが爆速生成し、私の名前でコミットされることにだいぶ耐えられませんでした。

そこで、コーディングエージェントにPythonを理解させようとClaude Codeのフックを使って教え込んでいます。
Claude CodeがPythonファイルを編集したときに、リンターを走らせ、「ロギングのメッセージにf-stringは使うべきでない」というエラーメッセージを見せて直すまで先に進まないようにブロックします。
LTではフックのデモをメインにし、さらなる工夫（サブエージェントの余地など）についてもお伝えします。
フック自体はPythonに限らず、自走するコーディングエージェントの一例になると考えています

概要

現代において我々は gpt-oss 等の優秀な事前学習済みモデルを自由に活用することができる恵まれた環境下にあります。
しかし、これらが会社の具体的なユースケースに完全にフィットしないケースも少なくありません。
私のバイト先のプログラミングスクールにおける生徒の離脱予測では、ユーザーの傾向の変化がしばしば相転移的な振る舞いをするために時系列のみを説明変数とする予測では相転移が起こる前に離脱の兆候を予測することができないという問題がありました。
そのため、時系列データに加えてテキスト情報を用いるマルチモーダルな推論が必要でしたが、これはデータの特性や制約によって既存のフレームワークでは対応できないという課題を抱えていました。
これに対し私は、既存の時系列基盤モデル (*1) のアーキテクチャを拡張する下記のライブラリを作成し、学習済みのモデルが拡張後のアーキテクチャに対応可能なように追加学習をする、という試みを行いました。
https://pypi.org/project/multimodal-timesfm/

話すこと

• そもそも時系列基盤モデルとは何なのか？実際のところ精度は出るのか？
• 事前学習済みモデルを自社サービスに特化させて活用するテクニックとしてはファインチューニングが一般的だが、なぜ「アーキテクチャ拡張」というアプローチを採るに至ったのか
• 基盤モデルを拡張する上での注意点、メリット・デメリット、今後の展望

補足

*1: 時系列基盤モデルとは、大規模言語モデルと同様の思想を時系列データに適用した機械学習モデルのことです。
言語モデルが大量のテキストデータで事前学習することで汎用的な言語理解能力を獲得するように、時系列基盤モデルは多様な時系列データで事前学習を行い、様々な予測タスクに適用できる汎用性を持ちます。

広告は「知らないサービスや体験への新しい出会いを作れる可能性」を秘めています。
私たちは「認知」のための広告ではなく「体験」をしてもらい、その体験から「よかった」と思える、そしてそれを実現できるプロダクト作りに日々励んでいます。
ですが広告主様×メディア様×生活者様と組み合わせが指数関数的に増え続け、人間ではカバーできない状況となっています。

AIを取り込んでいく中で「AIが体験を設計する」ことを見つけ、どう設計するか試行錯誤を重ねてきました。
驚くべきことに、既存の知識に縛られていない人たちがAIを柔軟に使いこなし、プロンプト設計を通じて組織全体が「AIの時代のエンジニアリング」を身につけました。

その過程で、組織は「ルール設計」に縛られており、体験設計の視野が狭くなっていることに気づきました。
「ガチガチに固めたルール」ではなく「コンテキストをおおまかに渡す」そうすることで、想定以上の体験設計を作り出すことに成功しました。
「正確性をどう上げるか」から「確度を持たせるために何を捨てるか」へチームの問い方が変わり、問題特定の速さも手に入れました。
「人の属人化は許容、AIの属人化はやめよう」本当の学習は、AIに任せるべきことを理解し判断を重ね、その反復を通じて得られるという組織における重要な価値観も形成されました。

AIへの投資を加速させ、会社のコア機能（プロダクト・DX基盤・AI基盤）をすべて繋げ、セールスも含めた全社でAIを組み込んだフローを使いこなしていく必要があります。
コアな部分がPerlだからこそ、エンジニアが「AIを使いこなし、レガシーと向き合う楽しさ」を感じ、同時に「AIも取り込んだ新しいアーキテクチャ思考」を磨いて価値を出していく——それがわたしたちの『Bet AI』であることをお話します。

私たちがAIにBetしたのは、「個人で使うAI」ではなく「チームで活用するAI」を実現するためです。
業務アプリ開発プラットフォーム「kintone」では、AIを使って“誰もがチームでより良く働ける環境”をつくることを目指しています。

AI開発の軸は「データ活用」と「市民開発」の2つ。
検索AIや分析AIでは、kintoneに蓄積されたデータから必要な情報を見つけ、チーム全体で知見を共有できるようにしています。
一方で、アプリ作成AIや設定レビューAIでは、専門知識がなくてもAIと相談しながら業務アプリを作れるようにし、市民開発を支援しています。

さらに、AIとの連携を支える技術基盤として「公式MCPサーバー」や「AIモデル JavaScript API」を整備し、開発者が自分たちのAIエージェントを柔軟に組み込める環境を提供しています。
これにより、社内外のサービスとAIを組み合わせた新しい活用が広がっています。

私たち自身の開発チームでも、設計レビューやドキュメント整理などでAIを日常的に活用し、開発のスピードと質を高めています。
このLTでは、プロダクトとチームの両面から、私たちがどのようにAIにBetしているのか、その背景と学びをお話しします。

カラオケ店舗の現場では、日々の「数字」と周辺商圏の状況や市況のトレンドといった「空気」を読みながらスペシャリストの経験と勘に基づいて売上を作っています。
しかし、全国400店舗分の売上データをすべて人の目で分析して追いかけるのは限界があります。店長は接客の時間を削ってレポートをまとめ、エリアマネージャーは複数店舗を管轄し、異常が起きていないかExcelと睨めっこしています。私たちはAI Agentによってその「人の手間」を減らしていきたいと考えています。

新たに構築したいと考えているAgentは、“現場が気づく前に店舗の異変に気づく”AI Agentです。
全店舗のPOSデータを監視し、売上の異常や傾向変化を自動で検知。異常が見つかると、周辺の天気・イベント・SNS投稿・競合店データを自動で収集し、「なぜその変化が起きているか」を分析してマネージャーに知らせます。
これを実現することで、マネージャーはお店の体験価値向上を“考えること”に集中し、店長は“お客様と向き合うこと”に集中できる。AIには「人間が人間にしかできないことに集中できる環境を作る存在」として店舗運営をサポートしてもらいます。

こうした仕組みを支えるために、私たちはデータ構造や分析フローを再設計し、店舗現場からのフィードバックを取り込みながら、AIが自然に働くシステム基盤の構築を目指しています。

AIが数字を追い、人が笑顔を作る。
テクノロジーが“現場を軽くする”とき、カラオケという価値は次のステージへ到達すると信じています。
その未来を、AI Agentと現場スタッフと一緒に作り上げていきたいと思っています。

「OSS」ってキラキラして見えるかもしれないけど、憂鬱になることがたくさんある。これまで愚痴を表に出すことはしなかったけど、このトークではあえてそれをさせてくれ。今までの苦労を成仏させてくれ。

僕は2021年の年末からHonoというOSSを作っている。それは驚くほど人気になった。2025年8月現在、GitHubのスター数は「26K」。日本人発のプロダクトだと世界で第3位の数字である。この規模のOSSを開発・メンテナンスをできるのは非常に貴重な経験で「僕にしか見れない景色」を見ている。今回はその景色を少しでもあなたに見てもらいたい。決して、OSSにコントリビュートすることを促すわけではない。ただ、あなたが使っているソフトウェアの背景にはとんでもないドラマがあるってことを知ってもらいたい。

具体的には以下のトピックを話します。

• Honoの現状
• 僕らはCPANで息を吸うようにOSSをしていた
• GitHubのInboxが恐怖
• ありがたいIssueと厄介なIssue
• Whyを聞かれると辛い
• Share a minimal project to reproduce it!
• 中学生コントリビューター
• 登山をしてたら向かいから集団が来て全員に挨拶しなくてはいけない問題
• 嫉妬される
• Noを言うのは大変
• やりたいことをシェアしない
• Hono Conference
• 外向的性格がOSSをやると
• You are a legend!
• 頑張ればなんとかなる
• そして、希望

まぁ、大変だけどすごく楽しいよ！

同タイトルのプロポーザルをYAPC::Hakodate 2024の際に出しましたが、個人的都合で当日行けなくなりました。テーマは同じですが、当時とは状況が変わっているのでアップデートした内容になります。

はてなアンテナは登録したURLの更新情報を定期的に取得し、更新内容をまとめるウェブサイト巡回サービスです。
サービス開始以来20年を越えたはてなアンテナでは、Perlで書かれたコードベースの置き換えを進めています。
最初の一手として、数百万件のページを効率よく巡回するクローラをGoで書き直しました。クローラをゼロからつくる中でおこなった実装の選択や、既存のクローラからの移行および運用、既存のバックエンドとのコミュニケーションなど、プロダクトを漸進的に新しくしている過程についてお話しします。

以下のような内容について話す予定です。

• モチベーション: PerlからGoへ
• 実装編
  • ストレージの選定
  • キューの実装
  • producer-consumer パターン
  • http.Transport
• 運用編
  • カナリアリリースと移行戦略
  • ローカル開発
  • テスト
  • 旧バックエンドとのコミュニケーション
  • 中間証明書の問題
  • 健全性の監視

このトークでは、技術の変遷とともにどのようにPerlが変化してきたのか歴史を探求しながら、最近のモダンなPerlを紹介していきます。

Perlを使っている人、かつて使っていた人、プログラミングに興味がある人、プログラミングの歴史に興味がある人など
そんな人たちに「懐かしい〜」「へ〜」と思ってもらえるような内容を、わいとんとkobakenの2人でお送りします。

1990年から2025年現在までのWeb開発を「インターネット掲示板（BBS）」を題材に駆け上がり、各時代の変化のキッカケや背景に触れていきます。

お品書きは次の通りです。

1. CGI
2. PSGI/Plack
3. 複雑化するプロダクトにPerlはどう立ち向かってる？
4. 外圧による変化
5. 未来はどうなるか

このトークは「エンジニアがこの先生きのこるためのカンファレンス」 の前夜祭企画をベースに、
YAPC::Fukuoka 2025 用に再編・改善した内容になります。

最近、大規模言語モデル（LLM）が急速に普及していますが、すべての分野でLLMが万能というわけではありません。例えば、金融やセキュリティといった高い信頼性が求められる業界では、回帰やブースティング系の "古典的な" 機械学習の技術が、今なお第一線で活躍しています。

その理由は、旧来の機械学習では「この取引は不正利用の可能性が80%」といったように確率を使って物事を予測したり、「なぜそのように予測値が出たのか」という理由を人間が理解しやすい形で説明できる点にあります。身近な例では、金融での与信スコアリングやカード決済や送金等の不正利用の検知などの "予測タスク" に機械学習が今でも使われています。

このトークでは、機械学習のユニークなポイントと私が機械学習を好きな理由について、過去に熱中して作っていた "競馬" を題材にお伝えします。勘や経験則、あるいは人間が地道に作るルールだけでなく、機械学習という道具を手に入れると、競馬の収支を改善するためにどのようなアプローチが可能になるのか？ 最近話題のLLMに尋ねるのとは、何が違うのか？私の過去の実践経験を元に、詳しく説明します。

機械学習について初めて知る人でも楽しめるよう、以下の流れでお話しする予定です。

• 機械学習の基本
  • 機械学習とは何か？特に教師あり学習について
  • 機械学習が使われている分野
  • 機械学習の利点と欠点
  • 機械学習のシステム構築の流れ
  • 最近の機械学習の潮流
• 競馬と機械学習
  • 競馬の簡単な紹介
  • 競馬に適した機械学習手法の紹介
• 競馬の勝ち馬予測モデルの作り方
  • 予測の元になるデータを集める
  • 予測の精度を高めるための特徴量エンジニアリング
  • 予測モデルの構築方法と評価手法
• 勝ち馬予測モデルの実践
  • 予測値の活用方法
  • 実戦での評価検証

本当です。そしてこの事は、2025年現代のプログラミング環境において意外で根強い影響をあちこちに及ぼしています。本Talkではその証拠を提示した上で、なぜそうだったのか、その結果どうなったかを論じます。

• 証拠 - Proof
  • 語彙 - Vocaburary
  • "use strict";
• 理由 - Reason
  • Y'all can pop it. but can you shift it?
• 影響 - Consequence
  • typeof null === "object"
  • "🐫".length !== ["🐫"].length
• 結論 - Conclusion
  • Why Javascript matters -- and Perl doesn't (so much)
  • It sucks? Then why are you suckin' it?
  • Q&A

35歳になる目前、私はそれまで当たり前のように身を置いていたプロダクト開発の現場から離れ、人事担当として急転身しました。
エンジニアにとって、近いようで遠い存在である人事。果たして、お互いのことをどれくらい理解しているのでしょうか？
エンジニアから見た人事、人事から見たエンジニア。両方を経験したからこそ分かる、お互いの誤解と理解。人事の日常業務のリアル、エンジニア組織への貢献の仕方、そして技術者と人事の間に橋を架ける意味について、転身してからの4年間の体験をもとにお話しします。

アウトライン

• 「コードを書かない」決断と「急」転身の理由
  • EMキャリアから「またコードを書く？」に対する違和感
  • 技術者アイデンティティ・クライシス
• 両方やったからこそ見えた世界
  • エンジニア時代に持っていた人事への誤解
    • 「人事って面接だけやってるんでしょ？」
    • 「技術のことなんて分からないでしょ？」
• 人事になって分かった人事の世界
  • 実際の日常業務とその深さ
  • 組織課題解決への真剣な取り組み
  • HR業界のプロフェッショナリズムとは
• 技術者出身だからできること
  • エンジニアとの信頼関係構築
  • 技術組織の課題理解と解決への貢献
  • 両方の言葉で話せることの価値
• 4年経った今の率直な感想と学び
  • コミュニティとの新しい関わり方
  • 「技術者 vs 人事」ではなく「技術者 & 人事」という視点
• 橋を架ける意味
  • 技術者のキャリアパスの多様性
  • 組織をより良くするための協働の可能性

聴衆が得られるアウトカム

• 人事という職種への理解
• キャリアチェンジの現実的な体験談
• 技術者と人事の協働の可能性

Web サイトの JavaScript や CSS はブラウザから閲覧できます。従ってそれらに機密情報が入らないよう、細心の注意を払わなければなりません。なになに? 「minify してるから大丈夫。」「モダンなフレームワーク使ってるから大丈夫。」...だって? 本当にそうですか?

機密情報の漏洩を招くポイントは、様々な場所に潜んでいます。このトークでは、一般的なWebフロントエンド開発で意識すべき漏洩ポイント、そしてその対策についてお話します。

• Source Map 経由での漏洩
• Client Component 経由での漏洩
• Next.js Pages Router の _buildManifest.json
• その他注意すべき漏洩ポイント
• 漏洩の確認方法
• 漏洩を防ぐには

JSer.info・textlint・jsprimerというプロジェクトを通じて、技術を使ってオープンソースを持続可能にすることを考えていました。
この発表では、興味本位で始めた日々の情報収集がツール開発を経て大規模プロジェクトの設計技術へ発展するプロセス、
読む→書く→伝えるの段階的変化と継続するための工夫についてお話しします。

まず「読む技術」として、JavaScriptの情報サイトである JSer.info （14年間で750記事）の更新を支える情報収集システムを紹介します。

• 参考: https://jser.info/2021/01/16/jser-10th/

次に「書く技術」として、読むだけでは物足りず「書いてみよう」と思った経験から始ったPromise本執筆時の表記揺れ問題をきっかけに作った、textlintについて紹介します。
書くことで増える読む量や、AI時代における文章品質の自動化の進化についても、textlintのMCP対応のデモも交えて紹介します。

• 参考: https://efcl.info/2022/06/29/why-create-textlint/

最後に「伝える技術」として、jsprimer という JavaScript 入門書を継続開発する際の文章設計について紹介します。
Design Doc による文章の設計、Living Standard アプローチ、既知→未知の原則、書きやすさより読みやすさを優先する設計思想などを扱います。
また、オープンソースとして100人以上がコントリビューターと参加してもらった仕組みやGitHub Sponsors/Open Collectiveによる経済も触れます。

• 参考: https://efcl.info/2025/05/24/tskaigi-2025-jsprimer/

普段から業務でPerlのWebアプリケーションを開発・運用している方であっても「cpanfileに ::XS とついたモジュールがいくつか並んでいるところまではわかっているが、難解そうで、実装を追ったりするのはなんとなく避けてしまっている」というような方は少なくないのではないでしょうか (かくいう私もそのような時期がありました……)。

そんなXS、Perlにおけるネイティブ拡張のための仕組みは、

• データベースクライアントなど既存のCライブラリへのラッパー
  • （libmysqlclientに対応するDBD::mysqlや、ImageMagickに対応するPerlMagickなど）
• ネイティブコードによる最適化がウリのライブラリ
  • （JSON::XS、Type::Tiny::XS、……）

など、Webアプリケーション開発において必須とも言えるモジュール群で使われている技術です。一方で、とっつきにくく思われている節があり、なかなか手ほどきを受ける機会もないように思います。

本セッションでは、普段Perlを読み書きしているがXSにはあまり触れたことがない方を主な対象に、XSモジュールに対する心理的なハードルを下げ、リファレンスなどを参照しながら既存のライブラリなどの実装を理解したり、トラブルシューティングができるようになることを目指します。また、Perlに馴染みがない方にとっても、スクリプト言語におけるネイティブ拡張の仕組みのケーススタディとして楽しんでいただければと思います。

トーク内容

• CPANモジュールを取り巻くツールチェインのおさらい
• XS "急"速入門
  • 「XS言語」の基本的な文法・構造から、外部ライブラリの呼び出しなど
• XSモジュール探訪
  • 実際のXSモジュールのコード読解

クラウドの利用が広がる中で、複数のプロダクトを横断して安定したインフラ基盤を提供することは、プラットフォームエンジニアリングにおける大きな課題です。

我々の組織hacomonoでは、1,000万人以上の登録ユーザーを抱えるサービスを提供しており、今後はさらに複数のプロダクト展開を計画しています。
これまでプロジェクトごとにAWSアカウントを発行し個別にリソースを管理してきましたが、組織の成長とともに、このやり方だけではスケールしていくのが難しいと考えています。

そこで現在、共通基盤をKubernetes上に構築する取り組みを進めており、その一つの施策として導入しているのが Crossplane です。
CrossplaneとはAWSやGCPなどのパブリッククラウドやKubernetesリソースなどをKubernetesの抽象で管理可能にするOSSのツールです。

Crossplaneによるリソースの抽象化は、開発者がより楽かつ安全にインフラを扱えるようにし、同時に基盤側も裏で進化を続けられる柔軟さをもたらします。
一方で、トラブルシューティング時の原因特定の難しさや、従来のIaCツールとは異なる運用フローへの適応、チーム全体での新たな技術スタックに関する知識共有などの課題も少しずつ見えてきています。

本セッションでは、Crossplaneの概要と、取り組みを通じて見えてきた可能性と難しさ、そして今後の展望を共有します。プラットフォームエンジニアや、Crossplaneの導入を検討している方にとって、参考になる話を届けられればと思います。

おしゃべりAIサービス Cotomo (https://cotomo.ai/) の開発のために必要な、ステートフルなAI agentを作る技術についてお話します。

「LLM」と「AI agent」の決定的な違いはなんでしょうか。そもそも「AI agent」の定義が人それぞれなので一概には言えませんが、人とコミュニケーションするのが主な仕事であるAI agentに関していえば、それは「状態」があるかどうかというのは一つの決定的な違いです。つまり、LLMは記憶を持たず、AI agentは記憶を持ちます。正確にいうと、記憶を持っているように見せかけています。

本セッションでは、そもそも「LLMがステートレス」とは何かという話から始め、ステートフルなAI agentのミニマムな実装を見せつつ、「AI agentの記憶」というテーマを深掘りします。

それにしても、この「AI agentの記憶」というものは大変厄介で、技術的にはすべての記憶を同時に持つわけにはいきません。そこで何らかの形で「今必要な記憶」だけを差し込みたいわけですが、そのあたりのソフトウェアエンジニアリング的な面白さも紹介できればと思います。