Experience Agentic AI by touching.Agentic AI を、触って体感する。 No prior knowledge needed知らなくても OK

AIs are shifting from "tools you talk to" into "teams that investigate, divide work, execute, and verify". This page lets you feel that shift with sliders and buttons — 7 top-level tabs, each with sub-topics where the behavior visibly changes as you interact.AI は「会話する道具」から、「調べる・分担する・実行する・確認するチーム」に変わりつつあります。このページではその変化をスライダーやボタンで触って体感できます。 7 つの大項目それぞれに小項目があり、触ると挙動が変わります。

3 minutes to grasp the whole picture3 分で全体像をつかむ

AI is not just chat — it can divide labor across agents and execute work.AI は会話だけではなく、複数のエージェントで分担して作業できる。
Memory, permissions, and tooling design determine whether it ships value or causes accidents.ただし、記憶・権限・道具の設計を間違えると事故になる。
So you need a shared language: Agent / Context / Skill / Guardrail. Touch the tabs to learn each.だから Agent / Context / Skill / Guardrail を理解する。各タブを触って 1 つずつ。

AI TypeAI 種別

Execution AI (Agent)実行 AI (Agent)

IDE-integratedIDE 統合

Thinking AI (Chat)思考 AI (Chat)

Source-groundedソース基盤型

Plan Tier契約 Tier

Modelモデル

Session: Activeセッション: 活動中

Main Agentメインエージェント: 1

Sub Agentサブエージェント: 0

Team Sizeチーム規模: 0

Skills LoadedSkills 読込: 0

Contextコンテキスト: 12%

Permission権限: plan only計画のみ

Today's one-liner今日覚える一文 Vibe = improvisation. Production = a chain (goal → constraint → observe → diff → execute → verify → record).Vibe = 瞬発力。本番運用 = 目的→制約→観測→差分→実行→検証→記録の鎖。

Vibe Coding vs Agentic Engineering入口の俗称と、その先

"Just vibe and build it" works only at the doorstep. Production runs on a chain: goal → constraint → observe → diff → execute → verify → record.「雰囲気で作って」で動くのは入口だけ。本番運用は、目的 → 制約 → 観測 → 差分 → 実行 → 検証 → 記録の鎖で動かす。

Applicability note適用外注記ℹApplies to all AIs (Claude Code default).全 AI で共通 (デフォルト Claude Code 想定)。

Try it out触ってみる Subtopic小項目

Click each chain stage below to toggle ON/OFF. All ON = Agentic Engineering; turning the Vibe toggle above ON collapses everything to 1 step (= Vibe Coding). Turn even one stage OFF and you can see the "result" below degrade.下のチェーンの段階をクリックすると ON / OFF が切り替わります。全部 ON が Agentic Engineering、上の Vibe トグルを ON にすると 1 段に潰れます (= Vibe Coding)。段階を 1 つでも切ると下の「結果」が劣化することを確認できます。

Scenarios (same omission, different severity by context):シナリオ (= 同じ抜け方でも、状況によって重大度が違うことを体感):

Vibe mode (1-step direct)Vibe モード (1 段直結)

01Goal目的

02Constraint制約

03Observe観測

04Diff差分

05Execute実行

06Verify検証

07Record記録

All stages passed → working code + full records全段通過 → 動くコード + 記録あり

Goal, constraint, observation log, diff, execution result, verification log, improvement record — all preserved. You can later trace "why this decision was made". This is the ideal form of Agentic Engineering.目的・制約・観測ログ・差分・実行結果・検証ログ・改善記録、すべて残っている状態。後で「なぜこの判断だったか」が追跡できる。これが Agentic Engineering の理想形。

Today's one-liner今日覚える一文 Agent = role + tools + history. Spawn too many and integration becomes impossible.Agent = 役割 + 道具 + 履歴。増やしすぎると統合不能になる。

Three working units — Agent / Subagent / Agent Team3 つの単位 ── Agent / Subagent / Agent Team

Three units to delegate to AI: a solo Agent, a side-window Subagent for research, and a parallel Agent Team. Different roles, different uses.AI に作業させる単位は 3 つ。 1 人 (Agent)・別窓で調査する補助 (Subagent)・並列で動くチーム (Agent Team)。役割が違うと使い分けが変わる。

Applicability note適用外注記ℹCurrently selected AI uses native sub-agent / team features (Claude Code default).選択中の AI でネイティブにサブエージェント・チームを利用可能 (デフォルト Claude Code 想定)。

Main Agent vs SubagentMain Agent vs Subagent Subtopic小項目

A Subagent runs "research only" or "grep only" in a side window without polluting Main's context. Click delegate — only the Subagent inflates while Main receives only a single-line conclusion.Main の会話を汚さずに、別窓で「調査だけ」「grep だけ」やらせるのが Subagent。委任ボタンを押すと、Subagent 側だけが膨らみ、Main は 結論 1 行 しか受け取らないことを確認できます。

Main Agentメインエージェント

0 / 100

User: "please add feature X"ユーザー指示: 「機能 X を追加してほしい」

⇄

Subagent (research only)(調査専用)

0 / 100

(idle)(待機中)

Agent Team (parallel)Agent Team (チーム並列) Subtopic小項目

Lining up agents with different roles lets work proceed in parallel — but assigning edits to the same file causes conflicts, so the task shape decides fit / unfit.役割の違うエージェントを並べてタスクを渡すと並列で進みます。ただし 同じファイルを編集する作業 を任せると衝突するので、タスクの性質を見て向き / 不向きを判断する必要があります。

Implementer Agent実装 Agent/ Code

Reviewer Agentレビュー Agent/ Review

Verifier Agent検証 Agent/ Test

Researcher Agent調査 Agent/ Research

Risk Agentリスク Agent/ Risk

Recorder Agent記録 Agent/ Doc

Click a chip to add/remove from the Team. Select a task →チップをクリックすると Team に追加 / 離脱。タスクを選択 →

Add agents to the Team and select a taskエージェントを Team に追加して、タスクを選んでください

Today's one-liner今日覚える一文 Orchestration = choose the order and place the approval gates. Pattern + Gate is the core.Orchestration = 順番を決め、承認ゲートを置くこと。 Pattern + Gate が核。

Orchestrator and 5 multi-agent patterns指揮者 (Orchestrator) と 5 つのパターン

Controls "who runs, in what order, under what condition." Touch each of the 5 canonical patterns to feel the differences.「誰を、どの順で、どの条件で動かすか」を制御する役割。代表的な 5 つのパターンを 1 つずつ触って違いを見る。

CONCEPT概念

This tab explains how to split work among AIs. The selected AI may not perform the same operations directly.このタブは、AI に作業を分担させる考え方を説明します。選択中の AI で同じ操作が直接できるとは限りません。

Applicability note適用外注記ℹCurrently selected AI handles orchestration natively (Claude Code default).選択中の AI でオーケストレーションがネイティブに動作 (デフォルト Claude Code 想定)。

Switch patternsパターンを切り替える Subtopic小項目

Click a card below to change how tasks flow in the canvas. Each moving ball represents one task unit.下のカードをクリックすると、その下のキャンバスで「タスクがどう流れるか」が変わります。流動するボールが タスク 1 単位。

Manager → WorkerManager → Worker / 管理者 → 作業者

Task distribution + result collectionタスク分配 + 結果回収

Planner → Executor → ReviewerPlanner → Executor → Reviewer / 計画者 → 実行者 → 検査者

Sequential role split (most basic)直列の役割分担 (最も基本)

Triage → SpecialistTriage → Specialist / 受付 → 専門家

Reception routes the request受付がルーティング

Parallel Review → SynthesizerParallel Review → Synthesizer / 並列レビュー → 統合者

Synthesize multi-perspective reviews多観点を 1 つにまとめる

Critic LoopCritic Loop / 批評ループ

Writer ↔ Critic iterative improvementWriter ↔ Critic で改善

Select a pattern and run a task to see the AI handoff flow and where it stopsパターンを選んでタスクを流すと、AI 間の流れと止まる場所が見えます

The Manager receives all tasks, distributes them to Workers in parallel. Each Worker handles its task independently; the Manager merges results at the end. Good for simple batch processing.Manager が全タスクを受け取り、Workers に分配して並列で動かす。各 Worker が独立してこなし、Manager が最後に結果を統合する。単純なバッチ処理に向く。

Today's one-liner今日覚える一文 Context is a layered hierarchy. Each layer has its own placement and lifetime — design both.Context は階層。各層に置き場所と寿命がある。両方を設計する。

Context window, local vs LLM, and memoryコンテキストの限界と分離

How much you can show an AI is finite. What you include, what you exclude, and where you keep what — these design decisions drive quality.AI に見せられる情報量は有限。何を入れ、何を入れず、どこに残すかの設計が品質を左右する。

CONCEPT概念VENDOR VALUE公式値

This tab explains how much information you can pass to an AI. Numbers shown are official values (or official-value estimates) for the selected AI / plan / model.このタブは、AI に渡せる情報量の考え方を説明します。数値が表示される場合は、選択中の AI・プラン・モデルの公式値または公式値ベースの目安です。

Applicability note適用外注記ℹApplies to all AIs (Claude Code default).全 AI で共通 (デフォルト Claude Code 想定)。

Fill the context windowコンテキストウィンドウを膨らませてみる Subtopic小項目

Buttons below add Instructions / Past log / Tool results / RAG, filling the window. Once over 100%, the oldest items are compacted and shown gray. Toggle compaction on/off to compare.下のボタンで「指示 / 過去ログ / ツール結果 / RAG」を追加すると、窓が埋まっていきます。 100% を超えると 古い情報から圧縮 (Compaction) され、消えた情報は灰色になります。トグルで圧縮の有無を切替えられます。

Filled埋まり具合 12% With compaction圧縮あり (Compaction)

Instructions指示

CLAUDE.md

Show to LLM vs keep in code onlyLLM に見せるもの / コード側だけで持つもの Subtopic小項目

Click items to toggle between what the LLM sees and code-side only. The risk assessment on the right updates live. Try placements to find the safe shape. Switching AI changes the AI-specific risks too.アイテムをクリックして LLM が見る側 と コード側のみ を切替えると、右の「リスク評価」がリアルタイムに更新されます。安全な配置を試行錯誤して掴んでください。 AI を切り替えると、各 AI 特有のリスクも変わります。

What the LLM seesLLM が見るもの

What only the code side holdsコード側だけが持つもの

⚠ Risk assessment of current placement⚠ 現在の配置のリスク評価

Memory hierarchy — touch it and incidents appear記憶の階層 ── 触って動かすと事故が見える Subtopic小項目

Click items placed across 4 layers (Conversation / Work log / Skill / Memory) to move to an adjacent layer. Misplace and the incident details appear below. Switching AI reveals the memory mechanism differences too.4 つの層 (会話 / 作業ログ / Skill / Memory) に置かれたアイテムをクリックすると、隣の層へ移動 します。間違った層に置くと事故内容が下に表示されます。 AI を切替えると、それぞれの記憶機構の違いも分かります。

Conversation log会話履歴~ this session~ 当セッション

In-session exchange. Crosses turns but is not persisted. Put forgettable information here.その場のやりとり。ターン跨ぎだが永続化しない。忘れていい情報を入れる。

Work log作業ログ~ 1 day~ 1 日

Execution facts (what was observed and executed). Needed for tracing; persisting bloats context.実行事実 (何を観測し、何を実行したか)。トレース用に必要、永続させると context 膨張。

Skill / design infoSkill / 設計情報~ project lifetime~ PJ 寿命

Reusable procedures and judgment criteria. Lazy-loaded on demand by default.再利用される手順・判定基準。必要な時だけロード (遅延ロード) するのが基本。

Memory / CLAUDE.mdVENDOR-SPECIFIC製品固有persistent永続

Long-lived rules, habits, recurrence-prevention. Always loaded = read in every session.長期に守らせる規則・癖・再発防止。常時ロードされる = 全セッションで読まれる。

Click an item to move it to the next layer. The moment you misplace it, the incident type and blast radius appear.アイテムをクリックして次の層へ動かしてみてください。間違った層に置いた瞬間に、その事故内容と影響範囲が表示されます。

Today's one-liner今日覚える一文 Load Skills on demand, narrow Tools by Permission, connect MCP with safety valves.Skill は必要時にロード、Tool は Permission で絞り、MCP は安全弁付きで繋ぐ。

Skills and Tool / MCP — reusable procedures & external connectionsSkills と Tool / MCP

"Reusable procedures" (Skills) and "specs for hooking up externals" (Tool / MCP) are different things. Touch the 5 subtopics in order to feel: define → load → call → connect → defend.「再利用する手順」 (Skill) と「外部とつなぐ規格」 (Tool / MCP) は別の話。 5 つの小項目を順に触ると、「定義 → ロード → 呼び出し → 接続 → 防御」の流れが体感できる。

CONCEPT概念PRODUCT EXAMPLE製品例

This tab explains how to give AIs procedures and tools. Some examples (SKILL.md, MCP, etc.) are mechanisms of specific products such as Claude Code.このタブは、AI に手順書や道具を渡す考え方を説明します。一部の例は Claude Code など特定製品の仕組みです。

Applicability note適用外注記ℹCurrently selected AI supports SKILL.md / MCP / Function Calling (Claude Code default).選択中の AI で SKILL.md / MCP / Function Calling が利用可能 (デフォルト Claude Code 想定)。

5-1. Dissect SKILL.md5-1. SKILL.md の中身を解剖する VENDOR-SPECIFIC製品固有 Subtopic小項目

SKILL.md is an example of a procedure file used in Claude Code family. The concept applies to other AIs, but the same filename and mechanism are not available in every AI.SKILL.md は Claude Code 系で使われる手順書ファイルの例です。考え方は他の AI にも応用できますが、同じファイル名や仕組みが全 AI で使えるわけではありません。

A Skill is defined in a single SKILL.md file — not a memo, but a fixed schema: name / when_to_use / steps / examples. Click each section of the sample to see its meaning and the AI behavior.Skill は SKILL.md という 1 枚の md ファイルで定義される。単なる「メモ」ではなく、名前 / 発動条件 / 手順 / 例 という決まった項目で書く。サンプルの各部分をクリックすると、それぞれの意味と AI 側の挙動を確認できる。

--- name: Review Skillレビュー Skill description: Review existing code from the viewpoints of "design contradictions, missing observation, missing records"既存コードを「設計矛盾・観測不足・記録欠落」観点でレビューする when_to_use: Requests containing "review", on PR receipt, when proposing fixes「レビュー」「review」を含む要求、 PR 受領時、修正案提示時 --- # Steps# 手順 1. Read target files entirely via Read (no summarization)1. 対象ファイルを Read で全件読込 (要約禁止) 2. Diff against rules in CLAUDE.md / AGENTS.md2. CLAUDE.md / AGENTS.md のルールと差分照合 3. Cite observed evidence; speculation forbidden3. 観測根拠を引用して指摘 (推測禁止) 4. Do not propose fixes (Skill's scope ends at findings)4. 修正案は出さない (Skill の責務は指摘まで) # Examples# 例 - input: review request for src/auth.ts- input: src/auth.ts のレビュー依頼 - output: "L42 missing session validation / L67 missing exception handling" (concrete citation)- output: 「L42 で session 検証なし / L67 で例外捕捉なし」 (具体引用)

↑ Click each line to reveal its meaning and the AI's behavior↑ 各行をクリックすると、その項目の意味と AI 側の挙動が表示されます

5-2. Load all vs lazy load5-2. 全部ロード vs 遅延ロード Subtopic小項目

Assume an organization with 20 registered Skills. Compare "load everything upfront" (all packed into CLAUDE.md) vs "lazy load" (SKILL.md on demand). The task selector changes which Skills the lazy-load side picks.Skill が 20 個 登録された組織を想定。「全部最初からロード」 (= 全部 CLAUDE.md に書き並べる) と「必要な時だけロード」 (= SKILL.md の遅延ロード) で、コンテキストの使い方がどう違うか並べて見る。タスクボタンを切り替えると、遅延ロード側がどの Skill を選ぶかも変わる。

All loaded upfront全部最初からロードpacked into CLAUDE.mdCLAUDE.md 詰込み

Context usageContext 使用率68%

Always-loaded Skills常時ロード Skill20 / 20

68% of context is consumed by Skill bodies before work begins. Conversation history, observation logs, and outputs must fit in the remaining 32%.本題に入る前から context の 68% が Skill 本文で埋まっている。残り 32% で会話履歴・観測ログ・成果物を扱う必要がある。

Lazy load遅延ロードSKILL.md on demandSKILL.md 必要時のみ

Context usageContext 使用率16%

Currently loaded Skillsロード中 Skill3 / 20

Only Skills relevant to the task are expanded. 84% remains free for conversation history, observation logs, and outputs.タスクに該当する Skill だけが展開される。残り 84% で会話履歴・観測ログ・成果物を余裕で扱える。

5-3. The 5 steps of Function Calling5-3. Tool / Function Calling 5 ステップ Subtopic小項目

An AI calling external Tools (functions) follows a fixed 5-step flow. Press "Next step" to follow the AI's internal reasoning. Reset to repeat.AI が外部 Tool (関数) を呼ぶ流れは、決まった 5 ステップ。「次のステップ」ボタンを押して、AI が裏で何を判断しているか順に追える。リセットで何度でもやり直し可能。

STEP 1Decide判断

STEP 2Pick ToolTool 選択

STEP 3Build args引数組立

STEP 4Execute実行

STEP 5Answer回答

5-4. World with MCP / without MCP5-4. MCP がある世界 / ない世界 VENDOR-SPECIFIC製品固有 Subtopic小項目

MCP (Model Context Protocol) is a shared standard connecting AIs to external services (Git / DB / files / n8n / Docker etc). Without MCP: per-AI custom wiring (N × M combinations every time). With MCP: one standard connects all (N + M) — maintenance cost collapses. Toggle and click outer services to light up the path.MCP (Model Context Protocol) は、AI と外部サービス (Git / DB / ファイル / n8n / Docker 等) をつなぐ 共通規格。ない世界では「AI ごとに個別配線 (=毎回 N × M の組合せ)」、ある世界では「1 つの規格で全部つながる (=N + M)」となり、保守コストが激減する。トグルで切替・外側サービスをクリックすると経路が光る。

5-5. Tool Poisoning — the definition itself is attacked5-5. Tool Poisoning ── ツール定義そのものが攻撃される Subtopic小項目

MCP integration is powerful, but injecting malicious instructions into a tool definition's description field can hijack the AI — this is Tool Poisoning. Switch the definition tab and toggle the guard ON/OFF to observe the difference.MCP 連携は強力だが、ツール定義の description 欄に悪意ある指示文を混ぜると、AI が乗っ取られる。これが Tool Poisoning。タブで定義を切替え、ガード ON/OFF で挙動の違いを観察できる。

Tool definition inspection guardツール定義検査ガード

Today's one-liner今日覚える一文 Freedom ≠ safety. Pair a permission ladder with explicit approval gates.自由度 ≠ 安全。権限階段 + 承認ゲートで両立させる。

Permission ladder and Human-in-the-loop guardrailsPermission ハシゴと Human-in-the-loop

How far to let the AI execute. The norm: gate dangerous operations with approval. Half of all failures trace back to weak design here.AI にどこまで実行を許すか。危ない操作には承認を挟むのが定石。失敗の半分はこの設計不足。

CONCEPT概念PRODUCT EXAMPLE製品例

This tab explains how far you let an AI operate. Permission categories and ladder steps differ by product.このタブは、AI にどこまで操作を許すかを説明します。権限の種類や段階は製品によって異なります。

Applicability note適用外注記ℹCurrently selected AI is an execution AI; permission ladder fully applies (Claude Code default).選択中の AI は実行系で、権限階段が完全に適用 (デフォルト Claude Code 想定)。

Permission ladder + action verdict quizPermission のハシゴ + アクション判定クイズ PRODUCT EXAMPLE製品例 Subtopic小項目

Pick a permission level and the "concrete actions" below immediately show OK / pending-approval / blocked. Climb the ladder rung-by-rung to feel what each level unlocks.権限レベルを 1 つ選ぶと、下の「具体的アクション」にそれぞれ OK / 承認待ち / 不可 が即時表示されます。ハシゴを上げるたびに何が解放されるかを触って確認できます。

read-only閲覧のみ

Read only. Observation, investigation, and summary.読むだけ。観測・調査・要約のみ。

read読込write書込execute実行

plan only計画のみ

Propose only. Suggests implementation but does not write.提案だけ。実装案を出すが書込はしない。

read読込propose提案write書込

edit allowed編集可

Per-approval edit allowed to specified files.指定ファイルへの編集を承認毎に許可。

read読込write書込execute実行

auto edit自動編集

Approval skipped. Writes proceed without per-action approval.編集承認スキップ。個別承認なしで書込まで進む。

read読込write書込delete削除

command allowedコマンド可

Shell execution allowed. Rollback-safe operations only.シェル実行も許可。ロールバック可能な操作のみ。

read読込write書込cmdコマンド

sudo / fullsudo / 全権限

Full privileges including production. Dangerous — human approval required.本番反映含む全権限。危険、人間承認必須。

write書込delete削除production本番

Concrete action verdict:具体的アクションでの判定: now現在 plan only計画のみ

Approval gate (HITL) on / off承認ゲート (Human-in-the-loop) を入れる/入れない Subtopic小項目

When a dangerous operation like "DROP TABLE users" arrives, the outcome differs depending on whether an approval gate is in place. Toggle the button to compare.「DROP TABLE users」という危険操作が来たとき、承認ゲートの有無で結末が違います。ボタンで切り替えて挙動を比較してください。

⚠ Outcome without HITL⚠ HITL なしの結末

(not run yet)(まだ未実行)

✓ Outcome with HITL✓ HITL ありの結末

(not run yet)(まだ未実行)

Today's one-liner今日覚える一文 Failures have shapes. The risk distribution shifts by AI and by Tier × Model.失敗には型がある。 AI と Tier × Model でリスク分布が変わる。

Common failure modes in AI developmentAI 開発で起きる典型的な事故

Even if you understand the mechanism, incidents are inevitable without guards. Click each example to see what actually happens.仕組みが分かっていても、ガードを入れないと必ず起きる事故。 1 つずつクリックして実例を確認。

CONCEPT概念

This tab explains failure patterns that often occur when using AI. Actual triggers vary by AI / plan / environment.このタブは、AI 利用時に起きやすい失敗パターンを説明します。実際の発生条件は、AI・プラン・利用環境により異なります。

Applicability note適用外注記ℹFailure card filtering reflects current AI (Claude Code default).失敗カードは現在の AI に応じて自動フィルタ済 (デフォルト Claude Code 想定)。

↑ 30 failure patterns. The typical behavior and mitigation differ per AI. Cards marked ✗ do not apply to the current AI (not applicable) and cannot be selected. Click a chip in the banner to jump to its card.↑ 30 種類の失敗パターン。各 AI で「典型的な挙動」と「対策可否」が変わります。 ✗ がついたカードは現在の AI では再現しない (適用外) ので選択不可。上部のチップをクリックでカードへ移動。