youtube版(スライド付き) 関連リンク Introducing Astra for Law 米OpenAI社は、最新のフラグシップAIモデル「GPT-6 Astra」をベースに、法律事務所やリーガルテック企業向けに最適化された新しい基盤ソリューション「Astra for Law」を発表しました。法律実務に必要な専門設定、データ、ツールを統合しており、API（モデル名: gpt-6-astra-law）などを介して高度な法律ワークフローを構築できます。以下に、日本のエンジニアに向けて、技術的な要点とアーキテクチャの魅力を分かりやすく解説します。 1. ドメイン特化型検索インデックスによる高度なRAG Astra for Lawの最大の特徴は、2億3000万以上のURLに及ぶ米国の判例、法令、裁判所規則などのデータを網羅した「法的検索インデックス」を標準搭載している点です。信頼性の高い一次ソースへ直接アクセスして推論を行うため、ハルシネーション（嘘の出力）を抑えた正確な回答が可能です。業界標準ベンチマーク「Vals AI’s Legal Research Bench」の評価では、通常のGPT-6 AstraによるWeb検索（正解率38.7%）に対し、Astra for Lawは「54.0%」の正解率を記録し、約40%もの性能向上を達成しました。判例の網羅性や、適切な引用箇所の抽出能力も大幅に向上しています。 2. リーガルグレードのセキュリティとデータガバナンス極めて厳格な機密保持が求められる法務分野に対応するため、セキュリティ設計が徹底されています。「Trusted Access Program」では、API利用時における「Zero Data Retention (ZDR: データ不保持)」が保証されます。さらに、ChatGPT Enterprise利用時のデータは、OpenAI側での人間によるレビュー対象からデフォルトで除外されます。倫理的な障壁（Ethical Walls）やアクセス権限の制御など、エンタープライズ開発で必須となるセキュリティ要件を高いレベルでクリアしています。 3. 独自ナレッジの統合とカスタム開発法律事務所が持つ独自の過去データ、交渉用のプレイブック、ノウハウをChatGPT EnterpriseやAPIに統合し、自社専用のAIツールを開発できます。すでに先行事例として、契約書からリスクを検知して自動で修正案を作成するシステムや、M&Aにおけるデューデリジェンス（企業調査）を支援するシステムなどが共同開発されています。 4. 既存ツールと繋がる豊富なエコシステム iManageやClioといった法務専用ツールと連携する「26種類のパートナープラグイン」が提供されます。また、法律実務で必須となるMicrosoft Word上で直接動作する「ChatGPT for Word」もリリースされ、ユーザーの既存ワークフローを邪魔しない優れたUXが設計されています。まとめ：新人エンジニアに向けた学びのポイント Astra for Lawは、汎用LLM（GPT-6 Astra）に「専門ドメインのRAG」「厳格なデータプライバシー設計」「外部ツールとのシームレスなAPI連携」を組み合わせることで、専門業務に耐えうるシステムへと昇華させた素晴らしい実例です。最先端AIを特定業界（ドメイン）に適応させるための設計パターンとして、非常に学びの多いアーキテクチャと言えます。引用元: https://openai.com/index/astra-for-law Migrating the GitHub Copilot runtime to Rust, using Copilot GitHub Copilotの中核である「エージェントランタイム」を、従来のTypeScript（Node.js/V8）からRustへ完全に書き換えた事例を紹介します。本プロジェクトは、Copilot自身（AIエージェント）を駆使し、実質的に1人の開発者がわずか数ヶ月で完了させました。チームで1〜2年は要する規模の移行を、安全かつ劇的に高速化させたアプローチと教訓は、新人エンジニアにとって非常に有益です。 1. なぜRustへ移行したのか？元のTypeScript版は、他言語（C#、Go、Pythonなど）のアプリから利用する際、不要なNode.js環境の起動や、約100MB以上のメモリ消費、プロセス間通信の発生がボトルネックでした。これを解決するため、依存関係を極小化し、他言語から「C ABI（C言語互換のインターフェース規格）」を介して直接同一プロセス内で軽量・高速に実行できる（インプロセス化）言語として、Rustが選定されました。 2. 開発を止めない「インプレース移行戦略」一度に全てを差し替えるのではなく、コンポーネント単位で段階的に移植する「インプレース方式」を採用しました。段階的な統合: napi-rsを使い、一時的にTypeScriptとRustが通信できる仕組みを構築。コンポーネントを1つRust化するたびに古いコードを順次削除しました。常にリリース可能: この手法により、移行期間中もmainブランチは常に正常動作し、本番リリースを止めずに合計135回のアップデートを安全にユーザーへ届けました。 3. AIエージェントの生産性とコスト AIは128件のプルリクエストを通じて、約83万行のRustコードを記述しました。 APIトークン費用は約12万ドル（約1,800万円）でしたが、過去の文脈を再利用する「プロンプトキャッシュ」のヒット率を96.22%に維持したため、費用を劇的に抑えられました。開発者自身の稼働時間は、並行作業を含めて実質3週間程度でした。 4. 移行から得られたエンジニアリングの教訓「コンパイルが通れば正しい」は迷信: Rustの厳格なコンパイラは型不一致などの単純なミスを即座に検知しましたが、型解釈のズレ（整数であるべきIDを実数f64でシリアライズしてしまい、受信側でパースエラーになる等）による仕様上のバグはすり抜けました。 E2E（エンドツーエンド）テストこそが命: 動作の正しさを最終的に担保したのは、コードの挙動を外側からテストするE2Eテストでした。AIエージェントが自ら都合よくテストコードを書き換えないよう「保護する」ことが極めて重要です。まず愚直に翻訳し、設計変更は後にする: 移植と「最適化・リファクタリング」を同時に行うと、バグ発生時の原因特定が極めて難しくなります。 5. 移行がもたらした劇的な成果処理速度: 起動・接続・1往復の処理時間が5.25秒から292ミリ秒へと18倍高速化。メモリ削減: 同時10クライアント実行時のメモリ消費が、1,383MBから126MBへ91%削減。結論開発者の役割は、コードを自分で書く作業から「問題の定義、設計の境界、テストによるガードレールの設置、成果のレビュー」という高レベルな意思決定へとシフトしました。これからのAI協働時代を生きるエンジニアにとって、本質を示す道標となる事例です。引用元: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/ TypeSafeのJevを正しく驚く、それってLLMでできませんか？近年注目を集めるTypeSafe AIの「Jev」は、一般的なLLMのように文章を生成するのではなく、ソフトウェアが直接利用できる「判断」と「確率」を高速に返す特化型モデルです。本記事では、「Jevの機能は既存のLLMでも再現できるのではないか？」という疑問を出発点に、具体的な検証を通じてJevの真の実力と技術的な位置づけを解説しています。まず、Jevの強みである「高速なJSON出力」についてです。通常、LLMにJSONを出力させると、1トークンずつ順番に文字を生成（自己回帰生成）するため時間がかかります。しかし、回答の選択肢（例：true/false、承認/却下など）が予め決まっている場合、必ずしもすべての文字列を生成させる必要はありません。賢い代替案として、「回答候補に対応する最初の1トークンの出力確率（logit）」だけをモデルから取得し、最終的なJSONはプログラム側で組み立てる手法があります。さらに、共通のプロンプト部分を「KV Cache（過去の計算結果のキャッシュ）」で再利用しつつ、複数の質問をバッチ推論で同時に処理すれば、出力待ち時間を劇的に削減できます。実際に軽量モデル「Gemma3 270M」を用いてこの手法を検証したところ、通常のJSON出力に比べて77倍という圧倒的な高速化を達成しました。次に、リアルタイム性が求められる「ゲーム（マリオ）のプレイ」での検証です。Jevは100ms前後という短い時間で判断を下せるため、ゲームのリアルタイム制御が可能です。検証の結果、Jevは比較対象のLLMよりも優れたプレイ結果を残しました。ただし、これには技術的な前提条件があります。前述の「1トークン目の確率（logit）を見る」手法を実行するには、API経由でlogitを取得できるモデルが必要です。現在主流の高性能な「推論モデル」の多くはAPIでlogitを取得できないため、今回の比較対象は一世代前の「非推論モデル」に限定されました。そのため、この結果だけで「Jevが最新のLLMより全面的に優れている」と結論づけるのは早計です。結論として、Jevの本質的な強みは「既存のLLMで不可能なことを実現した」という点よりも、「『確率を出力する』という実用的なインターフェースを、使いやすいAPIとしてパッケージ化して提供したこと」にあります。現在、一般的なLLMの推論速度やコストも急速に改善しており（例：DeepSeek V4 Flashの初期応答時間は約90ms）、大手AIベンダーが同様のAPIを提供すれば、既存のLLMでも同等のことが可能になる可能性があります。今後、Jevのような専用モデルがどれだけの独自価値を維持し続けられるか、エンジニアとして注目すべきポイントです。引用元: https://zenn.dev/nwn/articles/824026c76116e0 お便り投稿フォーム VOICEVOX:ずんだもん

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related