## モジュール 3: エージェントの構造化データ永続化を確保する このモジュールはボーナス編となっており、TiDB Cloud CLI を使ってエージェント専用の Starter データベースクラスタを簡単に用意できることを体験できます。エージェントは「ローカル優先」の軽量なデータベース構成を好むことが多いですが、実はクラウド上に小さく永続的なデータベースを構築するほうが、ファイルシステムと同じ感覚（「一度作ったら、いつでもどこでも使える」）で使え、エージェントにとって理想的です。 ファイルシステムはコードやビルド成果物、復元可能な作業スペースを保管するのに最適ですが、構造化された状態の永続化・クエリはデータベースが得意です。このモジュールでは `ti db` を使って TiDB Cloud Starter インスタンスを作成し、TiDB Cloud Filesystem と組み合わせて Hermes に統一エージェントストレージレイヤーを提供します。 ### 手順 1: Starter クラスタを新たに作成する - **[ターミナル 2](ssh://monitor1-ssh#2)** に移動し、下記のコマンドを実行します。Starterクラスタの作成、データベース`sol`の作成、SQLユーザーの準備、エージェント用データベースURLの生成までを行います。 > [!TIP] > TiDB Cloud Starter クラスタはサーバーレスかつ MySQL 互換のデータベースクラスタです。`ti` CLI の `--wait`, `--query`, `--output` フラグを使うことで自動化を簡単に行えます。複数の工程も1ステップでスクリプト化できます。 ```bash # TiDB Cloud Starterを作成 read DB_CLUSTER_ID <<< "$(ti db create-db-cluster \ --db-cluster-name hermes-data \ --db-cluster-type starter \ --region aws-${LAB:REGION_CODE} \ --wait \ --query "id" \ --output text \ )" # 標準ロール持ちSQLユーザー(admin, read_only, read_write)の作成 ti db create-db-sql-users \ --db-cluster-id $DB_CLUSTER_ID \ --region aws-${LAB:REGION_CODE} # エージェント用データベース（名前は 'sol'）の作成 ti db execute-sql-statement \ --db-cluster-id $DB_CLUSTER_ID \ --sql "CREATE DATABASE sol" \ --admin \ --transport mysql \ --region aws-${LAB:REGION_CODE} # エージェント用DB接続文字列生成 read DATABASE_URL <<< "$(ti db format-db-connection-string \ --db-cluster-id $DB_CLUSTER_ID \ --read-write \ --database sol \ --query "connection_string" \ --output text \ )" # DATABASE_URL を Agent 環境に渡す echo DATABASE_URL=$DATABASE_URL >> .hermes/.env ``` ```output { "cluster_id": "xxxxxxxxxxxxxx", "users": { "admin": { ... }, "read_only": { ... }, "read_write": { ... } } } { "fields": [], "rows": [], "row_count": 0, "transport": "mysql", "access_mode": "admin", "cluster_id": "xxxxxxxxxxxxxxx" } ``` ### 手順 2: エージェントにデータベースへアクセスさせる - **[ターミナル 1](ssh://monitor1-ssh#1)** へ戻り、Hermesを起動します。 > [!NOTE] > Hermes が試行錯誤しやすいよう、DATABASE_URL のパスワードを Herms が参照できるようにあえてセキュリティ設定を緩めています。 ```bash export HERMES_REDACT_SECRETS=false hermes chat ``` - 再度環境変数を確認してください。今度は `DATABASE_URL` が含まれているはずです。 ```text env を実行して ``` ```output ... - DATABASE_URL – MySQL connection string for TiDB Cloud ... ``` - StarterはMySQL互換なので、エージェントは特別な学習なしに`DATABASE_URL`さえあれば接続できます。 ### 手順 3: チャレンジ - 最後の課題です。Hermes に指示して、モジュール 2で使った「太陽系」Pythonプログラムを支えるデータ構造やデータを新たなデータベース `sol` へ移行しましょう。 - ちょっとしたデータベース移行プロジェクトとなるので、エージェントが案を見出すまで少し時間を与えてください。 - もちろん独自の方法で実施してもOKです。 - 推奨指示例は以下です： ```text TiDB Cloud Filesystem を /workspace にマウントし、Database URLを受け取れるPythonプログラムを使って、太陽系Pythonプログラムのデータおよびスキーマを sol データベースへ移行してください。 ``` > [!NOTE] > 演習で用いる LLM モデルの関係上、ミッションが完了するまで5分ほどかかる場合があります。 - エージェントが移行完了を返答したら、**[ターミナル 2](ssh://monitor1-ssh#2)** に切り替えましょう。Hermesが作ったテーブルを確認します。実際の結果は異なる場合がありますので、作成されたテーブルを注意して確認してください。サンプル出力には `moons` や `planets` テーブルが含まれていますが、あなたの結果は異なる場合があります。 ```bash read DB_CLUSTER_ID <<< "$(ti db list-db-clusters \ --db-cluster-type starter \ --region aws-${LAB:REGION_CODE} \ --query "clusters[?display_name=='hermes-data'].id" \ --output text \ )" ti db execute-sql-statement \ --sql "SHOW TABLES FROM sol" \ --region aws-${LAB:REGION_CODE} \ --admin \ --db-cluster-id $DB_CLUSTER_ID \ --output text ``` ```output +---------------+ | Tables_in_sol | +---------------+ | moons | | planets | +---------------+ ``` - planetsテーブルもできていたら、簡単なクエリでレコードをチェックします。 ```bash ti db execute-sql-statement \ --sql "SELECT * FROM sol.planets" \ --admin \ --db-cluster-id $DB_CLUSTER_ID \ --output text ``` > [!NOTE] > このコマンドはテーブル名が `planets` であることを前提としているため、まれに失敗することがあります。エージェントが別のテーブル名を使用した場合は、SQLクエリでデータベーススキーマを自分で調べるか、Hermesセッションに戻ってエージェントに正しい構造を尋ねてください。 ```output +-----------+-------------+---------------+--------------+-----------+----------------+---------------------+---------------------+ | planet_id | planet_name | japanese_name | english_name | has_rings | discovery_year | created_at | updated_at | +-----------+-------------+---------------+--------------+-----------+----------------+---------------------+---------------------+ | 1 | 水星 | 水星 | mercury | 0 | NULL | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | | 2 | 金星 | 金星 | venus | 0 | NULL | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | | 3 | 地球 | 地球 | earth | 0 | NULL | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | | 4 | 火星 | 火星 | mars | 0 | 1877 | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | | 5 | 木星 | 木星 | jupiter | 1 | 1610 | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | | 6 | 土星 | 土星 | saturn | 1 | 1655 | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | | 7 | 天王星 | 天王星 | uranus | 1 | 1787 | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | | 8 | 海王星 | 海王星 | neptune | 1 | 1846 | 2026-08-19 03:53:08 | 2026-08-19 03:53:08 | +-----------+-------------+---------------+--------------+-----------+----------------+---------------------+---------------------+ 8 rows in set ``` - もしくは、[ウェブコンソール](https://tidbcloud.com/tidbs) でエージェントが作成した `sol` スキーマを参照することもできます。`hermes-data` クラスタから `SQL Editor` を開きましょう。 ### 手順 4: ブレーンストーミング - **[ターミナル 1](ssh://monitor1-ssh#1)** でHermesが稼働中の状態に戻ります。 - Hermesエージェントは「ゼロインフラ」かつスケーラブルで耐久性の高い2つのストレージ（TiDB Cloud FilesystemとTiDB Cloud Starter）を獲得したので、それらを活用したメモリ管理改善のアイデアを尋ねてみましょう。 ```text TiDB Cloud Filesystem と TiDB Cloud Starter を活用して、あなたのメモリ管理をどのように改善できると思いますか？ ``` - 一例ですが、実用的な提案として以下のような回答が得られます。内容はエージェントやタイミングによって異なります。 ```output ╭─ ⚕ Hermes ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ 素晴らしいご質問です！TiDB Cloud Filesystem と TiDB Cloud Starter を組み合わせることで、メモリ管理を大幅に改善できる強力な可能性が生まれます。 1. マルチレイヤーメモリアーキテクチャ 現在の制約: - 記憶容量は最大2,200文字 - 構造のないフラットなリスト - 優先度や新旧の区別がない - メモリの検索やフィルタができない TiDB Cloudを活用した拡張アーキテクチャ: ┌─────────────────────────────────────┐ │ ティア1: アクティブメモリ │ │ (コンテキスト内, 2,200文字) │ │ 優先度・頻繁アクセス向け │ └─────────────────────────────────────┘ │ ┌─────────────────────────────────────┐ │ ティア2: 構造化メモリ │ │ (TiDB Cloud Starterデータベース) │ │ カテゴリ・メタデータ・関連 │ └─────────────────────────────────────┘ │ ┌─────────────────────────────────────┐ │ ティア3: アーカイブメモリ │ ... この強化機能の実装例: フェーズ1: データベース連携 ... フェーズ2: ファイルシステム連携 ... フェーズ3: スマートメモリ管理 ... フェーズ4: 高度な機能追加 ... この新システムで得られる主なメリット： 1. 無制限ストレージ: 2,200文字制限解消 2. インテリジェント検索: 関連した記憶だけ取得 3. バージョン管理: 過去の記憶状態へロールバック 4. 関連性マップ: 記憶どうしの繋がりを理解 5. 自動最適化: クリーンアップや再編成の自動化 6. セッション横断: 別Hermes間での記憶共有 7. 監査トレイル: 記憶の作成・更新・参照履歴を追跡 ``` - 以上で演習は終了です。以下の図の全体像もご理解いただけたかと思います。 ```mermaid --- title: コーディングエージェントの統合ストレージレイヤー --- flowchart LR subgraph region["クラウドリージョン"] style region stroke-dasharray: 5 5 subgraph temporary["短命レイヤー - エージェント用サンドボックス"] FS_CLIENT["ファイル"] DB_CLIENT["データ"] end subgraph persistent["TiDB Cloud 永続レイヤー - スケーラブル、常時稼働"] FS["ファイルシステム"] DB["Starter"] end FS_CLIENT -->|FUSE & POSIX| FS DB_CLIENT -->|SQL| DB end ``` - リソースのクリーンアップ セクションへ進んでください。