ドキュメントの翻訳と作成のための日英バイリンガルAIプラットフォーム

顧客企業が求めていたこと

顧客企業は日本のコンサルティング会社です。業務の一つとして、日本の建設会社が海外のプロジェクトや、米軍を含む外国の発注者のプロジェクトに入札し、それを遂行するのを支援しています。こうした仕事には日本語と英語の大量のドキュメントが伴い、建設会社にとっては言語の壁もあるため、その多くをこのコンサルティング会社が手伝っています。同社の少人数のチームは、技術マニュアル、仕様書、スプレッドシート、図面などのドキュメントを手作業で翻訳・作成しており、元になる資料はスキャンしたPDFであることが多くありました。さまざまな資料をもとに、契約関連書類も作成していました。

作業を速くしたいという要望がありましたが、譲れない条件がいくつかありました。チームは翻訳を自分たちで修正するため、出力は編集できる状態である必要がありました。翻訳して平坦化したPDFでは、チームの役に立たなかったのです。また、どちらの言語であっても、各ページは引き続きチームの誰かが確認する必要がありました。さらに、顧客企業はジョブごとのコストを請求とコスト追跡に使うため、その金額が見えるようにしておく必要もありました。

チームでの使い方

プラットフォームには、主なワークフローが2つあります。1つ目は翻訳です。ユーザーはPDFをアップロードし、翻訳の方向（既定の日本語→英語、または英語→日本語）を選び、必要に応じて指示を加えてジョブを開始します。1つのジョブに複数のPDFを入れられるので、ページ数に実質的な上限はありません。スキャンしたページは画像として、それを読み取れるAIモデルに渡されるため、別途テキスト認識（OCR）の工程は必要ありません。

プラットフォームは各ページを解析し、必要な出力を判断します。Word文書、Excelスプレッドシート、画像のいずれか、またはその複数です。出力の種類ごとの専門エージェントが、ページをその形式で作り直して翻訳します。ページは、大きさを設定できるバッチ単位で並列に処理できます。バッチを50にすると、50ページのドキュメントも2ページのものとほぼ同じ時間で処理できます。チームが数千ページをこのプラットフォームで処理できたのは、そのためです。

ユーザーの指示は、エージェント自身の判断を補います。スキルも同じです。ここでいうスキルとは、エージェント向けの指示をひとまとめにしたものです。ユーザーはアプリ内でスキルを作成・編集し、ジョブごとに使うスキルを選びます。

次に、ユーザーは左右に並べて表示するビューアーで結果を確認します。左が元のページ、右が翻訳されたWord、Excel、画像の出力です。1つのページに複数の出力がある場合は、それぞれに番号付きのタブがあります。WordとExcelの出力は、プラットフォームに組み込まれたオフィスエディターのOnlyOfficeで開き、複数の人が同時に編集できます。画像は画像エディターで開き、テキストや枠を加えたり、画像を差し替えたりできます。

ユーザーはページを手作業で修正することも、アプリ内の編集エージェントに修正を依頼することもできます。メモを書き込んだスクリーンショットを添付したり、変更したい箇所をページ上でクリックしたりして、意図をエージェントに示せます。データファイルやスキルを渡すこともできます。エージェントは専用の隔離されたクラウド環境で一度に1つの出力を扱い、加えた変更はそれぞれ新しいバージョンになるので、ユーザーは採用するかどうかを選べます。ページの準備ができたら、各出力の形式の編集可能なファイルとして、または翻訳のPDFとしてエクスポートします。PDFは、翻訳だけでも、元のページと並べた形でも出力できます。

2つ目のワークフローは、契約関連書類の作成です。エージェントが、PDF、Office文書、画像が混在する資料から書類の下書きを作成します。作業をToDoリストとして計画し、最大3つのサブエージェントを同時に実行して、Word、Excel、PowerPointのファイル、PDF、テキスト、画像を作成できます。下書きには、ページと行の範囲、シートとセルの範囲、セクションなど、資料内の特定の箇所を示す引用を付けます。下書き作成の画面では、左にエージェントとのチャット、右に下書きが表示されます。引用をクリックすると、出典の資料が下書きの横に開き、引用したページ、行、セル、セクションが強調表示されるので、レビュー担当者は各記述を原文と照らし合わせて確認できます。保存した下書きは、すべてバージョンとして残ります。

下の録画では、エージェントに製品データの提出図書を作成させています。提出図書とは、施工者が、提案する機器が仕様を満たしていることを示すために提出する書類です。エージェントは、2台の給湯器に関する11個のサンプルのソースファイルをもとに作業します。仕様書とその補遺（Addendum）から、現場調査メモまでが含まれます。

このジョブでは、サンプルのスキル、sample-house-styleも使います。このスキルは、提出図書の表紙とセクションの順序、適合性マトリクスの列と判定ラベルを定め、さらに、要件を変更する補遺、要件を満たさない製品、食い違う2つの資料、どの資料でも裏付けられない値の扱い方を定めています。

UIとアプリ内マニュアルは、どちらも英語と日本語に完全対応しています。

プロトタイプから本番へ

2025年10月から2026年2月にかけて、顧客企業の実際の業務フローに沿ってプロトタイプを作りました。その1つが、準備、下書き作成、Webリサーチ、Webコンテンツの要約を担う4つのエージェントによる下書き作成パイプラインです。セクションごとの計画と、メーカーのマニュアルやWebサイトを渡すと、日英バイリンガルの契約関連書類の下書きを作成し、不足している情報には人がレビューできるようフラグを立てました。スキャンした日本語の技術マニュアルについては、3つのアプローチを比較しました。レイアウトを再構築するOCR、翻訳した各ページをクリティック（批評役）エージェントがレビューする画像生成、そしてコード実行を伴うクリエイター／レビュアーのループです。

プロトタイプを通じて、本番の設計に関するいくつかの点が固まりました。すべてのページを同じパイプラインに通すより、ページごとに適切なエージェントへ振り分けるほうがうまくいきました。チームには、編集できる出力が必要でした。また、エージェントの操作には、コスト追跡と、出典までたどれる引用も必要でした。

顧客企業のスタッフは2026年3月に翻訳パイプラインの利用を始め、私は数回にわたるフィードバックを通じてスタッフと密に連携しました。6月4日に編集エージェントを、6月15日に契約関連書類エージェントを追加し、プラットフォームが完成しました。2026年6月から本番運用されています。

構築

プラットフォームの設計と開発を担当し、テスト、デプロイから継続的なサポートまで、顧客企業のチームと協力しています。

WebアプリはReactとTypeScriptで構築し、バックエンドはAWS上のFastAPIです。エージェントは、AIエージェントとマルチエージェントのワークフローのために私が開発したPythonフレームワーク、doc-processing-toolkitの上で動きます。ユーザーは、Anthropic、OpenAI、Google、Fireworksのモデルプロファイルから選べます。

エージェントのツールは、MCPサーバーをまとめた私の別のパッケージ、doc-processing-std-toolsが提供します。MCP (Model Context Protocol) は、AIエージェントがツールを使えるようにするための標準的な方法です。このプラットフォームでは、ツールは隔離されたe2bのクラウドサンドボックスで動き、各エージェントは自分の許可リストにあるツールしか使えません。

ジョブはサーバー上で実行されるため、ユーザーのブラウザーの接続が切れても処理は続き、ほかのユーザーもジョブの状況を確認できます。エージェントの処理はブラウザーにリアルタイムでストリーミングされ、途中でキャンセルすることもできます。ジョブの処理は、ターンが中断されてもジョブが使えない状態にならないように設計しています。

1つのジョブで、複数の人が同時に作業できます。アクセスはジョブ単位で制御しています。共同編集にはDynamoDBのリースとS3のcompare-and-swap書き込みを使い、ほかに誰が作業しているかを表示します。利用状況とコストはページ単位とエージェントのターン単位で記録し、管理者用ダッシュボードで請求とコスト追跡のためにレポートします。

品質の確認方法

すべての出力にはレビューのステータスがあり、レビュー担当者は高評価・低評価とコメントで評価できます。ページを再処理するとそのフィードバックが反映され、エクスポートの前にレビューを必須にすることもできます。

システム全体のレビューも行っています。2026年6月には、56ページのジョブを対象に体系的なレビューを実施しました。AIエージェントのチームが元のページと出力をすべて比較し、問題を原因（モデル、システム、またはその両方）と重大度で分類しました。その結果、ジョブ全体で1つの文書タイトルが5通りに訳されていたことなどが見つかりました。1ページ単位のチェックでは見つけられない、一貫性の問題です。

エージェントが従うハウスルールをまとめたスキルには、専用のリグレッションセットがあります。15件のテスト文書を変更のたびに再実行し、悪化した点がないかを確認するものです。確認は、スクリーンショットの自動比較と人の目で行います。

運用

プラットフォームの運用には、利用するチームとの協働も含まれます。チーム向けのセッションを開き、使い方や、第一印象にとどまらない活用方法を紹介しました。あるとき、チームのメンバーが、特定のExcelファイルのシートを1つコピーして記入する作業を契約関連書類エージェントができるのか、疑問に思っていました。そこで、その作業用のスキルを作り、ファイルを参考資料としてアップロードする方法を示したところ、適切な指示を受けたエージェントはまさにその作業をこなしました。チーム向けのセッションから日々のサポートまで、関係者とのやり取りは日本語と英語の両方で行いました。

リリース後は、本番環境で起きた問題にも対応しました。2026年7月には、障害の原因がファイルディスクリプタの枯渇、つまりサーバーのファイルハンドルが足りなくなったことにあると突き止めました。また、オブジェクトストレージの一覧取得の結果が、20,000オブジェクトを超えると警告なしに切り捨てられていた問題を見つけて修正しました。

コストの記録は顧客企業の請求書に使われるため、プロバイダーの請求額と一致している必要があります。『6倍の乖離』では、両者が一致しなかったジョブと、それを受けて私が変更した点について書いています。

今後の候補としては、音声入力、実行中のエージェントのリアルタイムな軌道修正、プロバイダーに依存しないWeb検索が考えられます。いずれもまだ実装していません。

成果

2026年3月から8月までに、顧客企業のチームは300件以上のジョブを実行し、合計7,000ページ以上を処理しました。この数字には、6月にプラットフォーム全体が稼働する前の、3月〜5月のフィードバック期間も含まれます。

このプラットフォームが対応する業務（翻訳、対話形式での編集、契約関連書類の作成）の大半で、チームの生産性はおよそ4〜5倍になったと私は推定しています。これはあくまで私自身の推定で、正式に測定したものではありません。

学んだこと

スプレッドシート、文章のページ、図面では必要な処理が異なるため、ページごとに扱い方を決めるようにしたことで、後に続く工程がシンプルになりました。出力を編集できるようにしたことで、チームはレビューや修正がしやすくなりました。また、2つの言語で仕事をするには、AIの出力を翻訳するだけでは足りませんでした。UI、マニュアル、サポートのすべてが、英語だけでなく日本語でも機能する必要があったのです。

チームがプラットフォームから得たものは、エージェントの能力と同じくらい、セッションやサポートにも左右されました。上で触れたExcelの例では、スキルと参考ファイルでそれが可能になることを私が示すまで、メンバーはエージェントにその作業ができるとは思っていませんでした。

また、要件を満たす最もシンプルな設計にすることも学びました。翻訳の工程は明確に定まっているので、プラットフォームが手順を決め、エージェントがそれを実行する固定のワークフローとして構築しました。自分で手順を計画し、取りうる行動の幅が大きい自律型のエージェントと比べて、時間とコストを抑えられました。契約関連書類の作成はジョブごとの違いが大きいので、そちらではより自律的なエージェントが適していました。タスクごとにその線引きをどこにするかは、設計上の重要な判断の一つでした。