同じ表が出ても、中身の手順が見えなければ信頼は積み上がらない。

AIエージェントを本番で使うとき、結果の正しさだけでなく「どの手順で作ったか」が問われる場面は増えています。Elicitのエンジニアリング責任者James Bradyは、Code w/ Claude 2026（2026年5月20日・ロンドン）で、研究エージェントを検証可能にする独自DSL「AshPL」の設計を約30分にわたって解説しました。本記事では、なぜ出力だけでは足りないのか、AshPLがどう動くのか、本番運用で何を押さえるべきかを整理します。

この記事でわかること

  • 同じ出力でも信頼度が変わる理由
  • AshPLが満たす3つの設計要件
  • 書く・解釈する・書き直すループの仕組み
  • コンテンツアドレス型キャッシュが効く理由
  • DSL導入を検討するときの判断材料

出力が同じでも信頼は同じにならない

Bradyは講演の冒頭で、次の問いを投げかけます。2つのシステムがまったく同じ出力を返したとき、信頼度は等しいか、というものです。

答えは「中身次第」です。静的解析ツールが「脆弱性なし、本番投入可」と報告したとしても、古いモデルが雑に判定したのか、最新モデルがツール呼び出しと批判的な再検討を重ねたのかで、受け取り方は変わります。メッセージの文言が一致しても、生成の仕組みが違えば別物として扱われます。

Bradyは「メカニズム（仕組み）が重要で、唯一正しい設計はない」と述べています。ドメイン、ユーザー、タスクによって、速度重視か厳密さ重視かのトレードオフは変わります。Elicitは論文検索や意思決定支援を扱うため、データの出所と再現性を重視する立場に立っています。

AshPLが満たす3つの要件

Elicitの研究エージェント向けに、Bradyのチームは次の3点を設計の軸に据えました。

可読性（legibility） — エージェントの手順を人間が部分的に確認できること。他のエージェントが批判的レビューをかけることも想定しています。

反復の忠実性（fidelity of iteration） — ユーザーが「ここを深掘りして」「別の観点を足して」と指示を重ねても、当初の意図からドリフトしないこと。途中でやり直しが必要になると信頼は損なわれます。

手順の忠実実行（faithful execution） — 確認済みの手順が、実際の処理でもそのまま実行されること。計画と実行がずれれば、検証の意味がありません。

この3点を同時に満たすには、エージェントの計画を人間が読める形式で固定し、実行側がその計画に従う構造が必要です。ElicitはここでDSLの採用に至りました。Bradyは「全員がDSLを使うべきではない」とも明言していますが、自社の要件には合致したと説明しています。

AshPLとは何か

https://claude.com/code-with-claude/session/ldn-ext-making-agentic-workflows-trustworthy-and-verifiable-with-a-custom-dsl

AshPL（講演内ではHPLとも呼ばれる）は、Elicitのエージェントワークフロー専用のドメイン固有言語（DSL）です。主な特徴は次のとおりです。

  • チューリング非完全 — ループ、再帰、ミューテーションを排除した純粋関数型の言語
  • Pythonの意図的なサブセット — 既存言語の学習データを活かしつつ、不要な機能を削った設計
  • 型付き — 型エラーを早期に検出し、修正コストを下げる
  • ドメイン固有プリミティブ — 論文取得や臨床試験データの取得など、科学研究向けの操作を言語組み込みで提供

AshPLのコードは「計画の図解」ではなく、実行可能な計画そのものです。Web検索、論文取得、スクリーニング、結合といった各段階がプログラムに書き込まれ、インタプリタがそのまま実行します。ユーザーは各アーティファクト（表やレポート）に対応するAshPLコードを開き、どの検索クエリや処理が使われたかを追跡できます。グラフ表示もAshPLから直接導出され、見た目だけの可視化ではありません。

書く・解釈する・書き直すループ

AshPLを中心に据えたElicitのコアエンジンは、次のループで動きます。

  1. Curator（キュレーター）がAshPLプログラムを生成する
  2. Pythonサービスが構文解析・型チェックを行い、抽象構文木（AST）を歩きながら解釈する
  3. 結果に応じてCuratorがAshPLを書き直す
  4. 再度、先頭から全体を解釈する

型エラーや構文エラーは、高コストなLLM推論の前に安価にCuratorへ差し戻されます。デモでは、最初の表生成時点でAshPLは100〜150行程度、セッション終盤の結合処理では約1000行に達していました。更新のたびにプログラム全体を書き直し、先頭から再解釈する設計です。

部分だけを差分実行すると、反復のたびに意図がずれるリスクがあります。全体再解釈は遅くなりがちですが、純粋関数型であるAshPLの性質を活かしたコンテンツアドレス型ストア（式のハッシュをキーに評価結果を保存）で、過去に計算済みの式は再計算をスキップします。Bradyはこのキャッシュがなければシステムが成立しないと強調しています。

システム構成と本番運用の要点

AshPLは言語定義だけでは完結しません。Bradyは「DSL自体の実装工数は全体のごく一部で、残りは普通のソフトウェアエンジニアリング」と述べています。実際の構成要素は次のとおりです。

コンポーネント 役割
UI ユーザーの操作をWebブラウザで受け付ける
イベントログ 操作を追記専用で記録（イベントソーシング）
Pythonサービス イベントの仲介、AshPLの解釈
Sandbox AshPLの生成・保存
Curator LLMを使いAshPLを執筆するエージェント
Gateway APIキーを隔離し、プロンプトインジェクション経由の漏洩を防ぐ

Curatorには複数のハーネス（Agent SDK、Piなど）を差し替え可能なラッパーを設けています。現時点ではPiとAnthropicモデルの組み合わせが最良とのことです。ユーザーが処理待ち中にチャットへ追加入力しても、計画を書き直して継続できる割り込み処理や、過去セッションの再開（リハイドレーション）も自前で実装しています。

評価体制も本番品質の柱です。プログラムを動的に生成・実行する系は評価が難しく、Elicitは専任の評価チームを置いています。BradyはDSLベースのシステムでは評価への投資を強く推奨しています。

速度より厳密さを選ぶトレードオフ

Elicitは速度と厳密さのスペクトルで、厳密さ側に寄せています。単純なクエリは速く返せますが、差別化の核は体系的な文献レビューや多段階の調査です。デモの研究ランドスケープ（生物学向け基盤モデルへの投資マッピング）は、合計で数時間規模の作業になりました。ユーザーは途中で「オープンソースとクローズドソースの比較」「GTM戦略」「規制機関との関係」などのレイヤーを自然言語で追加し、AshPLプログラムが段階的に伸びていきます。

最終的な表の見た目だけを見れば、最新のClaude Opusが直接生成したように見えることもあります。Bradyの主張は、厳密な手順を経て作られた表と、モデルがその場で吐き出した表は、ユーザーにとって本質的に異なる対象だという点です。検証可能なプロセスそのものに価値がある、という設計思想です。

DSLを検討するときの判断材料

Bradyは講演の締めくくりで、DSLは万能薬ではないと繰り返します。ただし、自社のプロダクトが信頼性・データの出所・堅牢性を中核価値に据えているなら、仕組みを可視化する設計は有力な選択肢です。実装時に押さえるべき点を整理すると次のとおりです。

  • 既存言語（Pythonなど）をベースにし、モデルが構文を一から学ばなくて済むようにする
  • ハーネスとモデルの差し替えを可能にするラッパーを用意する
  • 割り込み処理とセッション再開を自前で設計する
  • APIキーなどの認証情報をエージェントから隔離する
  • イベントソーシングで操作履歴を追跡可能にする
  • 動的に生成されるワークフロー向けの評価体制を整える

Anthropicのエンジニアリングブログでも、エージェントはステートフルでエラーが連鎖しやすく、プロトタイプと本番の距離は想定より大きいと指摘されています（参考）。出力の検証だけでなく、プロセスの検証を組み込む設計は、そのギャップを埋める一つの方向です。

仕組みを見える化することが本質

AshPLの教訓は「DSLを作れ」という単純なメッセージではありません。Bradyが繰り返すのは、メカニズムが重要だという点です。同じ表、同じ結論でも、手順が読め、反復しても意図が保たれ、実行が計画どおりであることが確認できるシステムは、ブラックボックスの出力とは別格の信頼を得ます。

本番エージェントを導入するチームにとって、AshPLは参考になる実装例です。計画をコードとして固定し、全体再解釈とキャッシュで忠実性と速度を両立し、イベントログと評価体制で運用品質を支える。この設計パターンは、研究支援に限らず、監査や説明責任が求められるエージェント全般に応用できる考え方です。