弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコムがエンジニア・デザイナーのサービス開発事例やデザイン活動を発信する公式ブログです。

右肩上がりのグラフが見たくて。売上直結の Agent を Claude Agent SDK で構築した

AI

「おおお。」と言われる右肩上がりのグラフ、皆さんも見るとワクワクしませんか？ どうしても右肩あがりにしたくて、あまり伸びていないときも、頑張ってスライドへ矢印↗︎を引いちゃった経験、私はあります。

今回は、しっかり伸びるグラフになった施策を通して、Agentを用いた取り組みと成果、そこから感じた内容を紹介したいと思います。

改めまして、弁護士ドットコム事業本部でプロダクトマネジメントをしている森川 (tettuan)です。

サマリ

  • 施策：150万件の弁護士Q&A情報をまとめ、ユーザーの関心軸に合わせて再編成

    • 課題：AI対応を求められた「みんなの法律相談」サービス
    • 狙い：足元の数値改善と、次期サービスへの道筋づくり
    • 結果：基準クリア。Agent化により運用を自動化
    • 効果：AIネイティブサービスの収益化に確かな手応え

  • 取り組み：

    • 段階的な作成(26本 → 300本 → 600本)で検証
    • SpreadsheetのGAS → Cursor → Claude Code → Agent化

  • まとめ：

    • AIでしか実現できないサービス設計があり、PdMでも手が届く距離に技術がある
    • 売上直結の場所で価値を検証すると、ダイレクトに次の景色が見える

サービスの概要

一般向けサービスとしての「弁護士ドットコム」には、「弁護士検索」と「みんなの法律相談」という２つの大きなサービスがあります。今回、「みんなの法律相談」において、「まとめコンテンツ」の作成を行いました。「みんなの法律相談」は、弁護士が回答するQ&Aサービスです。Q&AサービスをAI時代にどう適応させていくかもテーマとなっています。

施策について

売上直結の、伸びる場所で価値を検証した

このグラフは、Google Search Console における「まとめコンテンツ」のトラフィックです。みんなの法律相談の収益はトラフィック量に比例するため、よくも悪くもトラフィック数がKPI化する、分かりやすい事業モデルです。
今回の取り組みは、コンセプトの検証からスタートし、リリースによって次の3点を検証しました。

  1. 一般利用者に受け入れてもらえる価値があるか
  2. 課金してもらえる価値があるか
  3. AIを駆使しコストを極小化できるか

　
これらの全てをクリアし、直近では Claude Agent SDK を用いて自動化を果たしました。

まとめコンテンツとは

従来から存在する「◯◯まとめ」フォーマットの記事コンテンツです。表面的には、目新しいことはほとんどありません。
事業にとって意味があったのは、一般の方々が「自分の問題」に近いシチュエーションを求めているのではないか？という初期仮説の検証でした。（そのためにUXで重視した点も多々ありますが、今回は割愛します。）

また、ChatGPTの登場によって「問いへ答えを返すことのできるAIサービス」を意識していたため、将来的にAIサービス化することを想定に入れていました。その検証に最適で、かつ足元の収益化に貢献する手段が「まとめ」ることでした。

まとめコンテンツ表示の一例：

取り組んだこと

前提：
当初から想定10万本単位でのリリースを考えていました。法律トラブル領域でも、個々のトラブル事例はロングテールの分布となるため、多くの本数を「ひとが作る」ことは考えませんでした。
さらに、従来の開発ツールで「困っている人が読む」水準の品質を作り上げることは難しく、AI時代だからこそ可能なアプローチだと判断していました。

26本のリリース

単に量産するのではなく、役に立つテーマを広くカバーすることが重要です。

まず、Google Spreadsheet の GAS 環境から Azure OpenAI APIを用いてコンテンツを束ねることからスタートしました。
初期は、質を左右する重要な枠組みレベルの課題が現れ、水準をクリアしたのは 26本だけでした。300本を目指しましたが、簡単には実現できませんでした。

少ない本数ではあるものの、「まず検証」だと考えてリリースしました。リリースしてみると、26本でも最小限の基準をクリアしたため、次のフェーズに移行しました。

300本の見送り

次に、改めて300本を目指してリリースを計画しましたが、いくつかの観点で問題が発覚し、作ったUIや想定した体験の全てをリセットしました。
価値検証シナリオを見直し、アプローチを変えることを決めて、そもそも確かめたかった3点（1.閲覧行動、2.課金、3.自動化）へ立ち戻る機会となりました。

300本リリース

しばらく間をあけて、無事に 300本リリースに至りました。この時期に、先ほど示したUIが確立しました。
価値検証のため、閲覧行動に対し、2つの重要な仮説（課金条件を含む）を設定しています。Google Analytics等の行動データも入念に設定し、複眼的にデータを観測しました。掘り下げると長くなるので、今回は割愛します。

600本リリース

閲覧行動の指標は良好で、仮説へ設けた水準を超えました。そのため、すぐに次の検証へと進みました。 +300本し、合計600本です。 特に収益化について、明らかな結果が現れるよう検証しました。具体的な数字・検証ポイントを示すことはできませんが、複数のゲートを設けて、両極端のパターンが現れるよう、それぞれシナリオを持って試しています。

Agent 化について

前置きが長くなりましたが、続けて、Agent化する過程で見出せたポイントを紹介します。

Agent化の狙い

現在、Agentによる自動作成の実装を完了しました。
本施策では、「運営コストが成り立つ状態を維持できるか？」も大きなテーマでした。
嬉しい誤算で、企画段階から全自動化を目指していたため、Agent 化する際にも円滑に移行することができ、目立った困難はありませんでした。

Agent化した狙いは、高いROIの維持です。

ROIのキーファクターは以下の3点です。

  1. 売上： 新規獲得に貢献することが施策の狙いです。
  2. コスト： 施策を維持し続けるために、コストを極限まで下げます。
  3. 投下資本： 構築した資産のメンテナンス性を高め、追加投資を抑制します。

このうち、売上の獲得は施策そのものが担います。Agent化することで、生成コストを削減し、さらに追加投資を抑制しました。

基本構成

まず、コンテンツをAgentで作成するには、(1)データ、(2)プロンプト、(3)構築環境が必要です。

データ

入力データは当社が権利を保有する情報のみを用いています。データ本部の協力を得て、ファイルシステムベースでローカル環境へ配置しました。ファイルシステムでも十分な稼働を得られており、高度なRAGシステムは当面不要だと判断しています。
出力フォーマットはエンジニアと取り決め、AIが書き出す形式を定めました。質問と弁護士回答にはAI加工を入れず、従来からの内容をそのまま利用する設計になっています。

26本/Spreadsheet GASで構築していた時期は、単体データ起点での振り分けへ着目していました。 要素抽出や、タグ付与に近い概念です。事業ドメイン固有の枠組みを考えて「意味データ」を作りにいきましたが、イマイチでした。

その後、全てをリセットしたタイミングで、データ構造もリセットしました。 ユーザーの関心を中心に据えた施策ですので、既存データを操作するのではなく、意図のデータ化を重視しました。（既存DBに存在しないデータを作りに行きました。）

プロンプト

「まとめコンテンツ」のプロンプトは、 記事コンテンツを担当していたツツミさんが作りました。 彼女は、法律を学んでいた経験があり、弁護士ドットコム事業では営業も経験していました。今回、未経験のプロンプト作りに挑戦してもらいました。

現時点では、プロンプト制御のほとんどを彼女が実施しています。
少し前まで「Cursorのメニューの英語が読めないから、どうしていいか・・・」という状態でしたが、いまや、GitHubやTerminalも操作しています。（事前予想できないキャリア転換となり、これはこれで、大きなテーマかもしれません。）

本人いわく、子どもの頃に日曜大工が好きだったらしく、何かをBuildすることへの面白さを感じられて、前向きに取り組めているようです。

読んでいる方には、ツツミさんが誰なのか分からないと思いますが、プロンプト部分で重要な役割を果たした人がいるんだな・・と、ご理解ください。

GitHub 管理

ツツミさんへプロンプト構築の役割をお願いしたため、GitHub管理が避けられませんでした。
（Cursorを導入した目的のひとつには、Gitの操作を自然言語で行うためでもありました。）

コンテンツ構築に関しては、プロンプトを磨き込んでいくツツミさんと、全体のフローを構築していく私との役割分担（2名体制）でしたが、GitHubを通したことで、非常にスムーズに連携できました。

ツールの変遷（構築環境）

続いて、構築環境です。

GAS + API 時代

当初、OpenAI API を用いるためにAzure環境を用いていました。 自動化するには、当時のメンバーリテラシーや、更新容易性、UI＋自動化を考えるとGoogle Spreadsheet のGASが最適解でした。

そこで、行列でデータを抽出するツールを作り、GASからAPIを動かしていました。

ところが、行列の処理の組み合わせでは精度がイマイチでした。 人が読んで読みやすい流れにするには、単に「パーツの組み合わせ」では難しいと判明しました。

Cursor時代

300本リリースではCursorを利用しました。
途中で試行錯誤の期間があったものの、ある時を境にして、プロンプトを連続実行するだけで実現できるほど、プロンプト自体のガードレール設計ができあがりました。 プロンプト自体に、チェックポイントやリトライが組み込まれており、何層ものプロセス設計が組み込まれていました。（すごいぞツツミさん）

この頃は、2人でCursorを開いて、時々停止しているので「続けて」とプロンプト指示する毎日でした。

Cursor 2 時代

600本に向けて作業している頃、Cursorが worktree を利用したAgentモードを搭載した Cursor 2をリリースしました。
そこで並列稼働へと一気に舵を切ったのですが、Token消費が著しく、Token追加しながら試したものの、すぐに断念しました。

この頃から、Agentモードを手掛けていっても良いだろうと考えはじめました。

Claude Code 時代

CursorでのToken問題から、Claude Code へと辿り着いています。それまでも部分的に Claude Code CLI を -p で呼び出していましたが、全面的に利用することとしました。ツツミさんにもTerminalへ慣れていただきました。

Claude Codeでは、単純にプロンプトを流すだけではなく、Denoを用いてローカルツール化を進めました。特にファイルシステム操作は積極的にDeno/Shellへ置き換えました。

とはいえ、この段階では、Claude Code へ人間が指示文を渡す手順が必要で、お互いに画面から離れるわけにはいきませんでした。

Claude Agent SDK への取り組み

ツール化を進めるなかで、「プロンプトによる制御→部分的なツール利用」という形態から「TypeScriptがClaude Codeを呼ぶ構造」へと転換しました。Agent化です。この時に、Claude Agent SDK を利用しました。

置き換え自体は 2日ほどで対応を完了しています。
ツールとして利用していたShellも、このタイミングで全て TypeScriptへ移植しました。

その後、不具合を見つけては修正を繰り返し、安定化まで10日ほど要しました。

主な機能：

  • Git Worktree による並列稼働
  • Worktree 内部での進捗 State管理
  • プロジェクト全体での 作業割り当て管理
  • 作業取得からPR のレビュー→マージまで完結
  • 本数指定（本数分のループ処理）

並列稼働：

複数人の並列稼働でマージまで：

上記のように、自律的にブランチを作成し、worktree へ展開しながら作業を進めていきます。

（余談：並列稼働がうまくいったため、Git Graphを 無駄に bananaしてみました。Git Graph をみた時の私の心情を汲み取ってくれたようにスパークしています。）

内部では、並列タスク処理による速度アップ、コンペ方式（複数提案から最良のものを選ぶ方式）による品質向上策の2つを組み入れました。プロンプトでは制御が難しかったことも、Claude Agent SDK では簡単に実現できました。

その後、構築Agentだけでなく、修正対応（リリース後のメンテナンス）用のAgentを用意しました。

効果

コスト削減

プロンプトのみで自動化していた頃と比較し、Agent化によって以下の成果が得られました。

  • 処理速度が 6 倍になった
  • コンペ方式により品質が向上した
  • Token数が減少した（1本単価が下がった）
  • 指示の入力が不要になった（自分たちは他のことができる）

なかでも、停止していないか？と進捗を気にせずに過ごせるようになったのは、心理的・認知負荷的に重要でした。

追加投資の抑制

Agent化により、メンテナンス性が高まりました。

システムが運用に乗ると、モデルやツール（Claude Code ）の進化に追随する必要があります。 初期のプロンプトには、コンテンツ作成の指示と、ファイル操作のような自動化の指示が混在していました。 2つの役割を分けることで、TypeScriptをClaude Codeでメンテナンスしたり、処理ステップを改善することが容易になりました。

SDK利用のポイント

Claude Agent SDKの公式ガイド には、Claude Codeで使えるツールや機能、セッション管理、入力モードなどの説明が網羅されています。

開始時点では、これらの大半を意識することなく、使い始められました。

API利用との違い

Claude Agent SDK は資料が充実しており、事例もそれなりに豊富です。Claude Codeで Claude Agent SDK のAgent構築を行うと、ストレスなく実現できます。 （用途的には OpenAI の Codex Agents SDK も同様なので、様々な事例を集められると思います。）

Agentの重要な点は、プロンプトからAIを動かすのではなく、コードがプロンプトを作ってAIを動かす点です。今回は、元になるプロンプトや構築フローができていたので、単純に置き換えていくことができました。

API実行との違いは、「Claude Codeで動くプロンプトは、SDK経由で、そのまま動く」点です。従って、初期のプロンプト構築を手作業で完成させ、そのあとにAgent実装へと段階的に移行することが可能でした。

例えば、読んだり書いたりする処理は、「ファイルを読んで」とプロンプトへ記載し、Claude Code上でプロンプトを実行すると実現できます。 Claude Agent SDKでは、同じプロンプトを使って実行することができます。

API利用の場合は、ファイル処理等の前処理を、最初からコード側で実装しなければなりません。ここが、大きく異なる点です。

ハーネス構築

Claude Codeから実行する場合、プロンプトがツールを起動します。
Agentでは、TypeScriptがClaude Codeへプロンプトを与えます。初期プロンプトで動いていた箇所は、そのままでも動きました。

しかし、Agent化する目的には、TypeScriptで処理する箇所と、LLMに依存する箇所を切り分け、安定性を高めて業務を完遂してもらうことでした。 そのため、応答をTypeScript側で制御する必要がありました。

とくに、プロンプト処理では非効率な部分や、Claude Codeの判断が分かれる箇所は、積極的に置き換えていきました。
つまり、Git操作や入出力のプロセスを網羅的に行えるよう、イレギュラーケースも含めたハーネスの構築が必要となりました。

具体的には、初期プロンプトは幾十にも折り重なってガードレールを構成しているため、それぞれの衝突ポイントで制御を加えていきました。
例えば「見出し作成」といった処理の、見出し存在確認のような処理を置き換えていきました。（逸脱しそうな箇所を、明示的に制御していきます。）

見出しカウント部分の例：

[INFO] 14:32:36 有効な見出し数: 10
[INFO] 14:32:36 見出し一覧:
[INFO] 14:32:36   1. 子供の足音被害で引っ越し費用は請求できる？
[INFO] 14:32:36   2. 管理会社対応が不十分な場合の損害賠償
[INFO] 14:32:36   3. 分譲マンションの騒音トラブル解決法
[INFO] 14:32:36   4. 騒音で体調不良になった医療費は請求可能？
[INFO] 14:32:36   5. 深夜の騒音被害と緊急対処法
[INFO] 14:32:36   6. 大家や家主の身内が騒音源の場合
[INFO] 14:32:36   7. 外国人住民との騒音トラブル対処法
[INFO] 14:32:36   8. 騒音計測と証拠収集の具体的方法
[INFO] 14:32:36   9. 調停や訴訟での騒音問題解決事例
[INFO] 14:32:36   10. 騒音を出している側の対応と責任

単に見出しを作成するだけではなく、カウントしています。このカウント数によって、次の処理を決めています。こうした制御を、単に分岐するだけでなく、LLMへの問い合わせも含めたハーネスにしていきました。

Agent処理の改善サイクル

Agentからログを出力し、処理フローを分析しやすくしました。

目的は、

  1. 非効率なツール利用の把握
  2. リトライの改善

です。

行単位で読み込みやすく、かつ特定レコードを抽出しやすくするため、jsonl 形式としました。

ログを読み込み、回数が多く時間のかかる箇所を特定します。
とくにGlob/Readツールは遅く・頻度が高いため、TypeScript側で工夫する余地がありました。

エラー対応も、内容を指示文と合わせてLLMへ問い合わせることで、次の指示を導きだすようにしました。できる限りピンポイントな解決案を得られるよう、各処理ごとにログをみてパターン定義をさせました。（自分では読んでいません・・）

コンテクスト管理

これは、本来はAgent化のなかで取り上げる重要テーマかと思います。 ただ今回は、中間のプロセスを含めて、プロンプトだけで仕上げられるほど精度の高い状態であっため、敢えて作り替えずに移行しました。

行ったことは、書き出している中間生成物を、Markdown形式からYAML形式へ変更し、TypeScriptから扱いやすくした程度です。

他には、効率をあげる観点で行ったことはありました。 例えばTSVデータをスキャンする箇所で、縦横のRead処理を分割し、縦で1回目、横で2回目といった問い合わせに分割するような工夫を入れています。

振り返ってみて

良かった点

  1. まず、Agent 化する前に、プロンプトだけで自動化できていた点です。
    Claude Agent SDK の実装が容易だったのは、プロンプトが要件としても機能したからです。

  2. 次に、収益化可能な領域を選んだ点です。
    「汎用的なAIが登場する前には実現不可能だが、AIがあれば高確率で収益化できると分かっている領域」を手がけました。そのため、必要なコストをかけることができました。

  3. 続いて、自律的なAgentの登場を前提に進めた点です。
    Spreadsheetで構築していた頃から比べると、想定していたよりも早く到来しました。全自動の想定でなければロングテールを市場として選べませんでした。つまり「従来技術では無理だ。でも、全自動AIなら可能だ。」という領域を選ぶことができました。

「プロンプトだけで自動化」は、それなりに大変です。ですが、このプロセスはシステム構築が不要であるため、エンジニア不在でも要件出しを行うことができ、かつ重要なプロセスの発見にも繋がります。結果、全体のスループット向上へ寄与します。実現可能性を測るためにも、実施して良いプロセスだと考えています。

この時、収益化可能な領域で試すと、ゴール地点や速度（角度）を測る期間にもなるため、試算可能なデータを手に入れることもできます。

気をつけた点

  1. 不確実性の制御：
    LLMのアウトプットが確率的な挙動を示す箇所は、不確実性が存在します。安定化には、プログラマティックな対応と合わせる必要があります。 この点で「Claude Code からSub Agents/Skillsを使う」選択肢は消しました。Sub Agents/Skillsを使うかどうか、Claudeへ委ねることになるためです。Claudeへ判断を任せたいシーンでも、手段に選択肢がある場合は、明示的に選ばせる指示を入れました。

  2. ステータス判断：
    PRの状態や、レビュー結果については、しつこくステータス判断を入れました。 ルールベースの判断と、LLMによる判断の両方を入れています。

制御と判断に関して、例えば、とあるGit処理について以下のようにしています。 LLMがGitを熟知しているため、エラーメッセージの制御はTypeScriptで行わず、判定結果をLLMに分類させています。一方、TypeScriptは指定されたフォーマットを受け取るようにしました。 受け取ったアクションには、TypeScriptが実行できる方法も示されており、次にLLMへ指示するかTypeScript側で実行するかについて、選択肢のある状態を作り出しています。 これにより、無駄に --force しようとしたり、merge/squash/rebase が揺れることも無くなります。 このように、確率的に起こるであろう事象を、確実な選択肢へ変換するように気をつけました。

（前略）

## 前回の分析
${prev.analysis}

根本原因: ${prev.root_cause}

## 実行したコマンドと結果
${resultsText}

## 要求
実行結果を確認し、次のアクションを判断してください。

## next_action の意味
- "push": 修正完了、git push を実行してよい
- "retry": 追加のコマンドを実行してからpushを再試行
- "abort": 自動回復不可能、手動対応が必要

## 回答形式
**重要**: 以下のJSON形式のみで回答してください。説明文は不要です。

```json
{
  "success": true,
  "summary": "結果のサマリ（日本語）",
  "next_action": "push",
  "additional_commands": []
}
```

JSONのみを出力してください。`;

（注: コードの一部であるプロンプトは、ツツミさんではなく、Claude が書いています。）

難しかった点

  1. 排他制御：
    複数人の並列稼働において、円滑に動き始めた途端に、コンフリクトが頻発しました。
    処理速度が速くなるとGitHub経由の同期更新では追いつかず、1ステップごとの確認を入れる必要がありました。（常にリモートのコミットを優先させて解消しました）

  2. 再開処理：
    エラーが起きて中断するとき、全ロールバックするとLLMのコストが上がります。だからといって、仕掛かり状態からの再開を試みると、異常系パターンの作り込みが必要です。
    この点は、プロンプトだけで構築するよりも、考慮パターンが増え難易度が高まったと感じました。洗い出し切るまで、何度か試行錯誤しました。

再開処理に関連して、中間データをコミットするべきか悩んだのですが、worktree の起点と終点だけにしました。理由は「作り直した方が早い」世界が近そうだな、と感じたためです。ちょうど Opus 4.5 が安くなったり。　

コミット前の再開は試みるものの、混乱をきたすようなら潔く捨てるようにしました。 結果、一方通行の処理で完結でき、安定性を増すことができました。

やらないと判断したこと

  1. GitHub Actions での自動化：
    GitHub Actions での自動稼働も検討しましたが、すぐに見送りました。 既存CIの存在、コスト制限、アカウント管理、コードの共有などをトータルで考えていくと、考えることが多い一方で得るものが少ないと判断しました。

  2. コミットログのルール化：
    自動化が実現していくなかで、そもそも成果物の全てをコミットするべきか？も、疑問を感じています。Git での管理は便利なのですが、読まないコミットログを積み上げても意味がなく、最新版の管理と差分把握ができれば良いと感じました。中間プロセスを保存しないと決めた結果、処理は一方通行になりました。ブランチがあれば何をしたか分かり、必要なら変更から分析もできるため、コミットログは考えないことにしました。

進行中のログは詳細に書き出すものの、最新を追えていればよいため、こちらもローテーションにして古いログは廃棄しています。

大切にしたこと

AI活用によって「できること」ではなく、「価値のあること」を大切にし続けました。

足元では、安定出力への難しさもあるので、懐疑的な意見もありましたし、仕上がりについて「やはり質感が良くないのでは・・」という声も出ました。 一方で未来をみると、自律的な自動開発は間違いなくやってくる世界だと考えて、研究もしました。サービスにとっては、いずれ訪れる未来のほうが重要なので、もちろん未来側を探りにいきました。

ただ、そうした未来への見通し以上に大切にしたのは、価値があることへのフォーカスでした。 利用者にとっての「お金を払ってでも解決したい困りごと」の解消に役立つことを考え、実現手段として「まとめる」方法を考えていました。 これまでの技術では「まとめたいけどまとめられない」、手の届かない状況下ですから、進化著しいAIをみて「これは手に届きそうだぞ」という自然な感覚で取り組むことができました。

価値を基軸に手の届く技術を選んでいった結果が、「Spreadsheet + API → Cursor → Claude Agent SDK」へ現れていると、振り返ってみても感じます。

まとめ

今回は一般の相談者の困りごとに目を向けた取り組みを紹介しました。とくに、AIでしか実現できないサービス設計があり、PdMでも手が届く距離に技術があると強く感じました。

Agentといっても、人が割り込んでくることもない、非常にシンプルなワークフロー型です。それでも、いくつかの変数を組み合わせていくなか、考慮すべき点が複数あることも感じて頂けたのではないでしょうか。

また、収益化が見通せる場所へ実際に適用することの大切さも、改めて感じました。売上直結の場所で価値を検証すると、ダイレクトなフィードバック（右肩上がりのグラフ）が得られました。さらに未来への鮮明なイメージが持てると、自分自身にも活力が湧いてきます。やるべきことが分かると、自然と手を動かしていることに気づきます。

20周年を迎えた弁護士ドットコムがチャレンジする世界へ関心を持っていただきつつ、わずかでも皆さんのプロダクト開発の参考になりましたら幸いです。最後まで読んでいただいてありがとうございました。

今後の展開

さて、弁護士ドットコム事業は、一般の相談者向けサービスのAI化を行っていきます。（当社では法務のプロ向けサービスも立ち上がっていますが、それ以外のサービスでも、です。） 今回のまとめコンテンツは、最初の1事例です。社内でも「まずは、まとめ。」と言っており、今後は動的にし、多様なニーズに応えるサービスへと変化・成長していく予定です。

目指す姿

一方、弁護士法により、弁護士でなければ扱えない業務も存在しますから、すべてをAIへ置き換えることはできません。また、私自身は、その必要もないと考えています。

私たちが目指しているのは、「弁護士をもっと身近に」し、「110番、119番、弁護士ドットコム」のように、世の中から法律トラブルに悩む人をなくすため、社会に不可欠なインフラ、国民的サービスになることです。

今回の Claude Agent SDK を用いて小さな Agent を作った現在地は、小さな一歩です。しかしここから未来の景色をみると、よりイメージが湧いてきます。
もっと広範囲に活躍するAIネイティブなシステムへと構想を拡大していくと、私たちがやるべきことが見えてきます。

実は同じタイミングで、弁護士の方々へ向けた取り組みも開始しています。双方へ、AIネイティブなサービスを作っていきます。 もし未来像に関心を持っていただけたら、直接の機会があれば、お話しできるかと思います。ぜひご連絡ください。お待ちしています。

© Bengo4.com, Inc. 2005