オフショア開発の現場では、IT Communicatorの仕事のなかに「難しくはないが、とにかく時間がかかる」ものが少なくありません。更新された設計書を訳し直す。新しい画面のテストケースを一式そろえる。テストを始める前にテストデータを用意する。AIの活用範囲が急速に広がるなか、弊社でもこうした繰り返しの多い作業をAIに任せてみました。本記事では、その結果を脚色せずにまとめています。効果がはっきり出たところも、今はまだ人がやったほうがよいところも、両方書いています。

IT Communicatorの仕事は「通訳」だけではない

IT Communicator（以下COM）は、プロジェクトの通訳だと思われがちです。しかし実際の担当範囲はもっと広く、ベトナム側の開発者・プロジェクト管理者と、日本側のエンジニア・お客様をつなぐ役割を担っています。その責任はプロジェクトの立ち上がりから終わりまで続きます。

図1. IT Communicatorはプロジェクトの両端をつなぐ位置にいる。

COMの仕事は、設計書をベトナム語に訳すことだけではありません。設計書を読み込んで業務ロジックを把握し、記述が曖昧な箇所を見つけて日本側にQAを出します。設計書の難易度によっては、開発チーム向けに設計説明会を開くこともあります。さらに、UT（単体テスト）およびIT（結合テスト）のテストケース作成、テストデータの準備、実際のテスト実施、バグ修正後の再テストまで担当することもあります。日本側との打ち合わせでの通訳や進捗報告も、COMの役割です。

これらを並べてみると、性質の異なる二つのグループが見えてきます。ひとつはコミュニケーションと判断の領域で、人に強く結びついており代替が難しい部分です。もうひとつはドキュメントとデータを処理する領域で、多くは決まった型の繰り返しです。弊社ではまず後者にAIを取り入れてみました。具体的には次の四つの業務です。

効果の前に ― 使用ツールとデータの線引き

ツールについては、下記の業務のほとんどをVS Code上のGitHub CopilotとClaude Codeで行っています。あわせて、プロジェクトチーム自身が書き、使うたびに手を入れてきたinstructionやskillを併用しています。本記事で扱う時期に使用していたモデルはClaude Sonnet 4.5で、現在はClaude Opus 5に切り替えています。

オフショア開発において設計書はお客様の資産です。そのため、AIに何かを渡す前にいくつかの原則を決めました。入力データを学習に使わないことを明示している法人向けサービスのみを利用すること。作業に必要な範囲だけを渡し、必要のないドキュメントを丸ごとアップロードしないこと。実データやシステム接続情報などの機微な情報は削除または置き換えること。そして最も重要な点として、AIの利用範囲はお客様と合意した枠内にとどめ、開発チームだけの判断で広げないことです。

AIに任せた四つの業務

図2. 四つの業務におけるAIとCOMの役割分担。

ドキュメント翻訳

最も早くAIを導入した領域であり、効果が最も分かりやすく出た領域でもあります。

Markdown、Word、PowerPoint、PDF ― 形式を問わず、AIは訳文を返してくれます。COMに残るのは、それを読み直して気になる箇所を直す作業です。

特に触れておきたいのは、すでに翻訳済みのドキュメントに日本側が追記した場合です。この繰り返し作業を専用のskillにまとめました。変更箇所だけを訳すこと自体は以前からCOMがやっていたことですが、違うのは、コミットを確認し、変更範囲を特定し、既存訳の該当箇所を探し、文体を合わせて差し込むという一連の流れが自動で動くようになった点です。手間がかかり、見落としも起きやすい工程でした。

図3. コミットに基づく訳文更新の流れ ― skill化の前と後。

導入初期、COMがまだAIを使いこなせていなかった頃には、開発チームがCOM専用の翻訳用Webページを用意してくれていました。Markdownをアップロードして少し待つと、訳文のダウンロードリンクが返ってくるという簡単なものです。その後、VS Code上のGitHub CopilotとClaude Codeに全員が慣れるにつれ、このページは自然と使われなくなりました。

設計ロジックの読解

以前は、設計書が分かりにくいとCOMは何度も読み返し、それでも腑に落ちなければ日本側にQAを出していました。現在は、分かりにくい箇所をAIに説明させ、示唆を得ることができます。そこから、ほかに確認すべき点が見つかることもあります。また、業務フローをあらかじめ要約させておくと、設計説明会がスムーズに進みます。

とはいえ、ここでAIが判断を下すわけではありません。AIの役割は「二人目の読み手」です。速く読め、何度でも読み返せ、二つの記述が矛盾している箇所を指摘してくれます。検証して結論を出すのは、あくまでCOMです。なお、翻訳やテストケース作成とは異なり、この業務は専用のinstructionを用意せず、開いているドキュメント上でAIと直接やりとりしています。

UT・ITテストケースの作成

テストケース作成の要件を専用のinstructionにまとめ、「書き手」の役割をAIに任せました。AIは設計書に沿ったテストケース表を出力し、COMはレビュー側に回ります。漏れているケースを補い、誤ったケースを削り、使用前にもう一度設計書と突き合わせる、という流れです。

UTとITは別々のinstructionに分けています。出力形式がまったく異なるためです。UTは画面単位・API単位で作成し、ITは複数画面をまたぐ業務シナリオを、権限ごとの視点で記述します。

テストデータの準備

複数テーブルにまたがる制約を持つ画面では、テストデータを手作業でそろえるのに相当な時間がかかります。親テーブルのレコードが一件欠けただけで、その下のデータ一式が意味を失います。現在、SQLの作成はAIの担当です。COMがテストケースに必要なデータを説明すると、AIがDB設計をもとにSQL文を書き、あとはインポートしてケースを順に消化していくだけです。

ただし、AIが担えるのは技術的な制約の部分までです。AIが書くSQLは関連テーブル間の外部キーは満たしますが、データは各テストケースが求める業務条件も満たす必要があります。そこはCOMが設計書を読み取り、あらかじめ指定しなければなりません。

どれくらい時間が短縮できたか

図4. 三つの業務で短縮できた時間（概算）。

まずお断りしておくと、以下の数字は主観的な概算です。チーム内のCOMが、同種の作業についてAI導入前後の体感と非公式な記録を比較したものにすぎません。統制のとれた計測結果ではありませんので、正確な数値というより変化の大きさの目安としてお読みください。

翻訳の50〜80%という数字には補足が必要です。初日から出ていた数字ではありません。導入初期は、訳文のフォーマット調整と用語統一に時間を取られ、一方で節約した分をもう一方で失っていました。速度が本当に上がったのは、instructionを十分に書き切ってからです。

テストデータの約50%は、テーブル間の関連をたどってSQLを手書きする工程がなくなったことによるものです。残りの工程 ― インポート、実行、そしてテストケースが求めるデータになっているかの確認 ― は依然として必要です。

テストケース作成の約50%は、ある種類の画面に限った話です。そしてそこが、弊社が最もはっきり限界にぶつかった場所でもあります。詳しくは次の章で述べます。

この三つの数字のほかに、設計ロジックの読解では時間では測れない、想定外の成果がありました。AIはロジックの穴を指摘するだけでなく、修正の方向まで提案してきたのです。もちろん検証せずに使うことはできません。ただ参考情報として扱うだけでも、QAを作成する際にはかなり助かっています。検証を経たうえで、「ここが不明確です」と尋ねるだけでなく、具体的な案を添えて日本側に判断を仰げるようになりました。

結果を捨てて一から書き直した話

すべての業務で同じ結果が出たわけではありません。翻訳はかなり良好でした。テストケース作成は画面によって差が出ました。権限が1階層しかない画面では、AIが生成したテストケースはほぼそのまま使え、時間も半分ほどに減りました。一方、権限が何層にも入れ子になっている画面では、AIは十分な量のケースを出力したものの、そのほとんどで権限の割り当てを誤っていました。修正すべき箇所が多すぎ、一件ずつ直すより新しく書いたほうが早い状態です。結局、出力をすべて破棄し、手作業で一から書き直しました。

とはいえ、AIにこの作業ができないと結論づけるつもりはありません。振り返れば、AIはプロンプトに反したことをしたわけではなく、プロンプトがそれを求めていなかっただけです。問題は二点あり、どちらも弊社側にありました。ひとつは、当時のプロンプトが権限階層間の制約条件を十分に書き切れていなかったこと。もうひとつは、複数の条件が重なる推論をモデルからうまく引き出せていなかったことです。いずれも改善可能であり、現在その方向で進めています。

一定期間運用してみて得られた三点です。

1. 出力の品質は、instructionやskillの品質にそのまま比例します。 一回目の実行でそのまま使えるものが出てくることはまずなく、実際の効果は数回の調整を経てから現れます。
2. 業務ごとに評価すべきで、まとめて評価してはいけません。 同じツール、同じプロジェクトでも、画面の種類が違えば結果はまったく異なりました。
3. COMの役割は失われるのではなく、移動します。 重心は自分の手で成果物を作ることから離れ、レビューと、引き渡すものに責任を持つことへ移っていきます。

しばらく使ってみての実感

正直なところ、始めた当初は試してみるという程度の気持ちでした。一番の心配は、本当に時間が短縮されるのかという点です。AIの訳文も結局は一行ずつ読み直す必要があり、専門用語は誤訳され、フォーマットも崩れる ― それを直していたら自分で訳したほうが早いのではないか、と。あわせてもうひとつ気がかりだったのが、この設計書はお客様のものであり、AIに渡してよいのか、どこまでなら渡してよいのかという点でした。

AIへの期待が変わってきたのは、個々の業務に落とし込めるようになってからです。たとえばコミットに基づく訳文の更新です。コミットを確認し、変更箇所を特定し、既存訳の該当箇所を探して新しい内容を差し込む。以前は半日かかっていた工程が、いまは数分で終わります。また、COMが何度読み返しても気づかなかった設計書の矛盾を、AIが指摘してくれたこともあります。

意外だったこともいくつかあります。前述のとおり、AIはロジックの穴を指摘するだけでなく修正案まで出してきます。さらに、プロンプトを書くこと自体が習得すべき技術だと分かりました。一行の指示を投げるだけでは、期待どおりの結果はまず返ってきません。プロンプトの書き方が上達するほど、返ってくる結果も良くなっていきました。

最後にひとつ、上の数字だけを見ると誤解されやすい点をはっきりさせておきます。短縮できたのは主に「作る時間」であり、「読み直す時間」はほとんど変わっていません。現時点でAIはCOMの日常業務の一部になっており、試しに使ってみるものではなくなりました。それでもAIはあくまで作業を支える道具であり、判断を下す立場にはありません。

おわりに

全体を振り返ると、型が決まっている業務では短縮効果は大きく、COMの時間の使い方が変わる程度には十分です。ただし、数字は物語の半分にすぎません。

残りの半分は、一人ひとりの仕事への向き合い方にあります。どこかにすでにあるものを打ち直す時間が減り、どんな道具にも代われない部分 ― 業務を正しく理解すること、適切な箇所に的確な問いを立てること、そして引き渡すものの品質に責任を持つこと ― により多くの時間を使えるようになりました。