🎃

# 「社長がMCPでこれ書いた」——翻訳業界の痛みをAIエージェントで検証した話

に公開
Model Context Protocol
Claude
ldx
structflow
tech

川村インターナショナル / LDX Lab

痛みから始める

翻訳の現場には、地味に厄介な問題がある。

IR文書や法務文書を汎用MTに通すと、数字のフォーマットが崩れる。敬語が文体と合わない。社内固有の用語が別の訳語に化ける。「また手直しか」という作業が、翻訳後工程の大半を占めることがある。

これは翻訳ツールの問題というより、「構造化されていないテキストを、文脈なしに処理する」ことの限界だ。会議の議事録でも同じことが起きる。誰が何をいつまでにやるのか、テキストの中に埋まっていて、読まないとわからない。

今日やろうとしたのは、「その工程をAIエージェントに任せたらどうなるか」の検証だ。

自分のスペック

最初に正直に書く。私はエンジニアではない。

弊社にはCTOがいる。コードを読める人間もいる。でも今日の検証は、自分一人でやった。使ったのはClaude.aiのチャット画面と、MCP経由でつないだ自社API（LDX hub）だ。コードは一行も書いていない。

「非エンジニアがAIエージェントを使うとどこで詰まるか」という記録でもある。

構成：MCPでAPIをつなぐ

今回の構成はシンプルだ。

Claude（チャット）
  └── Zuplo MCP（APIゲートウェイ）
        └── LDX hub
              ├── StructFlow   ← 非構造化テキストを構造化JSONに
              ├── RefineLoop   ← 翻訳後の用語・品質改善
              └── RenderOCR    ← PDF・画像からテキスト抽出

LDX hubは自社で開発しているAPIサービスだ。翻訳・OCR・データ構造化を扱う。ZuploというAPIゲートウェイの上で動いていて、ZuploにはMCPサーバーの機能がある。

つまり、ClaudeにZuplo MCPをつなげば、Claude自身がAPIを呼び出す判断をしてくれる、という構成になる。

つなぐまでの話（詰まったこと）

接続手順は3ステップだ。

  1. ZuploダッシュボードでAPIキーを発行
  2. Claude.aiの設定でMCPサーバーを追加（URL + APIキー）
  3. 接続確認

簡単に見えるが、ステップ1で詰まった。

Zuploのダッシュボードのどこからキーを発行するのかが直感的にわからなかった。ドキュメントを読んで探した。後でVOC分析（後述）をしていたら、同じ体験を書いたユーザーレビューがあった。

"Honestly struggled with the initial setup.
 Figuring out that API keys are issued from the Zuplo
 dashboard wasn't obvious. But once it was running,
 StructFlow's accuracy was satisfying."

これは今日StructFlowで処理した架空レビューデータの一件だが、リアルだと思った。チュートリアル動画は作る。

検証1：会議議事録からアクションアイテムを抽出

つながってから最初にやったのが、会議議事録の構造化だ。

やりたいことをそのまま伝えた。「5件の議事録から、担当者・タスク・期限を抽出してほしい」。

Claudeは自分でジョブを組んだ。

{
  "model": "anthropic/claude-sonnet-4-6",
  "system_prompt": "会議議事録からアクションアイテムをすべて抽出してください...",
  "example_output": {
    "action_items": [
      { "assignee": "田中", "task": "バグを修正する", "due_date": "2026-05-02" }
    ]
  },
  "inputs": [
    { "id": "minutes-001", "data": { "text": "..." } }
    // 5件を一括投入
  ]
}

自分はこのJSONを書いていない。ClaudeがcreateStructFlowJobというツールを自分で選んで呼んだ。

結果：5件・13アクションアイテムを11秒で抽出。成功率100%。

面白かったのは、「田中が4月22日までに修正する。（※本日時点で修正済みと確認）」という文から、期限と完了フラグを分離して取り出したこと。単純なキーワード抽出ではなく、文脈を読んでいる。

検証2：100件のレビューをVOC分析

次にやったのが、アプリレビューのVOC（Voice of Customer）分析だ。

「仮称Flowraというタスク管理アプリの日英混在レビュー100件を分析したい」と伝えると、Claudeは：

  1. レビューデータ100件を自分で生成した（日本語70件・英語30件）
  2. 2ジョブを並列でStructFlowに投入した
  3. 結果が返ってきたらHTMLレポートに整形した

自分がやったのは「やりたいこと」を3行で伝えただけだ。

抽出した項目はこの5つ：

各レビュー → StructFlow → 構造化JSON
              ├─ sentiment（positive / negative / neutral）
              ├─ nps_score（0–10の整数）
              ├─ evaluation_axes（評価軸・スコア・コメント）
              ├─ mentioned_features（言及機能名）
              └─ improvement_requests（改善要望）

結果：100件全件成功。処理時間はバッチ1が69秒、バッチ2が59秒。出力文字数は入力の4.3倍（33,791文字）。

4.3倍というのは、単純な分類ではなく評価軸ごとのコメントが自動生成されているからだ。「使いやすさ：タスク管理が本当に楽になった（positive）」のような形で、100件×複数軸で生成される。

集計してみると、推奨者（NPS 9-10）が37%、批判者（0-6）も37%という二極化が見えてきた。価格への不満と機能への熱狂が共存している、典型的なプロダクトのパターンだ。

気づいたこと：「意図を理解する」の正体

今日一日で気づいたのは、MCPでツールが使えるようになると、Claudeはツールの呼び出し方を自分で決めるということだ。

自分はStructFlowのAPIリファレンスを読んでいない。バッチ投入のやり方も知らなかった。でもcreateStructFlowJobを呼び出し、getStructFlowJobでポーリングし、完了したら次に進んだ。

これはコード補完とは違う。タスクを分解して、ツールの制約の中で自律的に実行している。

ただ、前提がある。ツールのスキーマが正確に定義されていること。 Zuploがパラメータを正確に公開しているから、Claudeは正しい引数を渡せる。スキーマが曖昧だと、意図を理解する前の段階で止まる。

正直な評価

できたこと：

  • 「やりたいこと」を伝えたら、ジョブ組み立て・投入・ポーリング・整形をClaudeがやった
  • 日英混在テキストでも品質が落ちなかった
  • 非エンジニアでも、つながれば実際に動くものができた

できなかったこと・課題：

  • 接続の初期設定はそれなりに詰まる。特にAPIキーの発行場所がわかりにくい
  • APIキーをチャットに貼ってしまい、セキュリティ的にまずかった（即再発行した）
  • ブラウザからAnthropic APIへの直接呼び出しはCORSでブロックされた（別の方法で迂回した）

失敗も含めて書いておく。「一発でうまくいった」記録より、詰まったところがわかる記録の方が再現性がある。

今日のまとめ

検証 件数 処理時間 成功率
会議議事録 → アクションアイテム 5件 11秒 100%
レビュー → VOC構造化 100件 69秒 + 59秒 100%

どちらも、自分がやったのは「やりたいことを伝える」だけだ。

次にやること

  • 「プレーンLLMで十分じゃないの？」を検証：同じ議事録100件をAnthropic APIに直接投げた場合との比較（第2回）
  • TermWeave（近日公開）：XLIFFと用語集を渡すと文脈を読んで用語を適用する
  • 英語版をdev.toに投稿：この記事の英語版を出す予定

MCPは「つなぐまで」が少し大変だ。でもつながれば、あとはClaudeが動く。こちらはやりたいことを伝えるだけでいい。それは、エンジニアでなくても変わらなかった。

LDX hub の検証事例：[https://ldxlab.io/ldxhub/case]
*StructFlow / RefineLoop / RenderOCR /

Discussion