AIエンジニア会議の英語: 分からないと言いながら信頼を失わない方法

はじめに：この分野でいちばん多く言う言葉

AIチームの会議の記録をざっと眺めると、目につくことがあります。シニアであるほど、確信する文を使いません。代わりに、分かっていることと分かっていないことの境界を引く文をよく使います。この二つはまったく別の能力です。

英語の会議の教材はたいてい逆を教えます。自信を持って話せ、あいまいな表現を減らせ、と。一般的なオフィス環境では正しい助言かもしれません。ところがAI開発では、この助言をそのまま守るとかえって信頼を失います。

理由は、この分野の数字がすべて条件つきだからです。どの評価スコアも、どのハーネスで、どの審査者で、どのデータで測ったかによって変わります。リーダーボードとベンチマークの読み方で整理したとおり、自己申告の数値、ハーネスの違い、審査者の偏りは例外ではなく基本条件です。そういう分野で条件を付けずに数字だけを言う人は、自信があるように見えるのではなく、条件を知らない人に見えます。

ですからこの記事の主題は一つです。AIの会議でいちばんよく必要になる英語は、確信の言語ではなく、不確実性を信頼感をもって表現する言語です。分からないという言葉を無能に聞こえないように言える力が、この分野の核心的な会議技術です。

なぜ早い段階の「分からない」が信用資産になるのか

まず、なぜこれが損ではないのかを整理します。この論理を自分で納得していないと、実際の会議でその文は出てきません。

不確実性を正確に言う人は、確実だと言うときに信じてもらえます。逆に毎回確信する人は、一度外した瞬間からすべての数字に割引がかかります。これが実質的な損です。次に本当に確実な結果を持っていったとき、その確信が伝わりません。

二つ目の理由はこの分野の構造から来ます。隠した回帰は必ず表に出ます。ほかの人が同じ評価を回し、別のチームが同じモデルをつなぎ、最後には利用者が見ます。遅く出るほど費用が大きくなります。すでにその結果の上に別の決定が積み上がっているからです。

三つ目は時間です。原因をすべて突き止めてから報告するという態度は誠実に見えますが、その間にチームは間違った前提で日程を組みます。情報がなくてできなかった決定と、間違った情報ですでに下した決定は、回復の費用が違います。

この記事には結果をよく見せるための文がありません。意図的に外しました。そういう文は一度か二度は通用し、そのあとは通用しなくなりますし、通用しなくなった時点ではすでにキャリア上の費用が発生しています。

信頼感のある不確実性の三つのかけら

分からないという言葉が無能に聞こえるのは、分からないからではありません。どこまで分からないのかを言わないからです。同じ状況から出た二つの文を比べてみます。

[信頼を失う形]
I'm not sure. I'll look into it.

[信頼を得る形]
I don't know yet whether it's the model or the harness.
What I do know is that it started after Tuesday's deploy,
and it only shows up on the long-context slice.
I'm bisecting the commits and I'll have an answer Thursday.

二つ目の文にも、分からないという言葉はそのまま入っています。情報量が違うだけです。ここに入った三つのかけらが、この記事の骨格です。

境界が抜けると無能に聞こえます。分からないという状態だけを報告したことになるので、聞いている人にできることがありません。

根拠が抜けると軽く聞こえます。同じ82点でも、一度回した値なのか五回の平均なのかでまったく別の文なのに、その違いが消えます。

次の段階が抜けると回避のように聞こえます。ここがいちばんよく抜けます。分からないと言ったあとに黙ると、相手が次の行動をつくらなければならず、そうなると分からないと言った代償を相手が払うことになります。

以下の場面別の表現は、すべてこの三つのかけらの変奏です。表現を覚えるより、どのかけらが抜けているのかを見る目を養うほうが長持ちします。

状況1：評価結果を発表しながら限界も一緒に言う

いちばんよく来る状況であり、いちばんよく失敗する状況です。よくある失敗は、数字を先に言って限界をあとから付けることです。そうすると限界が言い訳のように聞こえます。限界を先に言ってから数字を渡すと、同じ内容が慎重さとして読まれます。

数字を言うときに一緒に付けるとよい条件が四つあります。どのデータか、何回実行したか、どの審査者か、何と比較したか。四つすべてを言う必要はありませんが、一つも言わないと、その数字は会議室で実際より固いものとして流通します。

状況2：回帰が出たのに原因がまだ分からないとき

ここでいちばん大きい誘惑は、原因を突き止めてから言うことです。一日を惜しんでチーム全体の三日を燃やす選択です。

Heads up はエンジニアリングの会話では標準に近い表現ですが、口語です。役員に上がる文書や格式のあるメールでは I want to flag を使うほうが合います。この判断は会社の文化によって違います。文書でもカジュアルなトーンを使うチームでは、わざわざ変える必要はありません。

No action needed from you yet は短いですが効果が大きいです。悪い知らせを聞いた人の最初の反応はたいてい自分が何をすればよいのかであり、その質問に先に答えておくと、報告はずっと軽く受け取られます。

状況3：指標は上がったのに実際の品質は上がっていないとき

この分野でいちばん言いにくい状況かもしれません。よい知らせを自分で取り消す場面だからです。しかしこれを言わないと、チーム全体が間違った方向に一四半期を使います。

この状況にはすでに名前があります。リワードハッキングです。指標は本当に上がったのに課題は失敗している状態を指し、システムの故障ではなく、私たちが定義した目標をそのとおり最適化した結果だという点が核心です。

英語圏のMLチームでは That might be Goodhart のようにグッドハートの法則を略して呼ぶ言い方が通じます。ただしこれはMLチームの中だけで通じる略し方なので、他部署が混ざった会議では開いて言うほうが安全です。We may be optimizing the measure instead of the thing we care about くらいなら誰にでも伝わります。

状況4：データ品質とラベリングの意見の相違

ラベリングの議論が長引く理由は、たいてい人々が互いに別のことを議論しているからです。モデルが間違っているかを争っているつもりが、実はラベルの定義を争っている場合が多いのです。先に何を争っているのかに名前を付ける文が、いちばん時間を節約します。

六つ目の文には、レジスターについての判断が入っています。ラベル品質の問題を提起すると、その作業をした人やチームを批判しているように聞こえやすいのです。批判の対象を人から指針に移すと、同じ問題提起がずっと安全に伝わります。そしてたいていはそれが事実でもあります。ラベルが揺れる本当の原因は、作業者の誠実さではなく定義のあいまいさであることが多いのです。

七つ目の文は論証としても強いです。人の間で一致しない基準をモデルに要求するのは不可能な要求だという指摘なので、反論しにくいのです。

状況5：コストと遅延のトレードオフ

この会話でエンジニアがよくやる失敗は、技術的な判断と事業的な判断を混ぜて言うことです。二つを分けて言うと、発言の重みはむしろ上がります。自分の領域では断定し、他人の領域では情報だけを渡す形です。

四つ目の文がこの節の核心です。that's a product call, not a technical one は、自分の意見を明かしながら決定の権限は相手に残します。意見を出さないのでもなく、他人の決定を代わりにするのでもない位置をつくってくれます。

最後の文は三つのかけらのうち根拠にあたります。推定値と測定値を区別せずに言うと、あとで実測が違って出たときに信頼が削られます。推定だと明かして言った推定は、外れても費用がありません。

状況6：研究の日程と製品の日程がぶつかるとき

研究はいつ結果が出るか分からず、製品は日付を必要とします。この衝突は解決されず管理されるだけなので、管理可能な形に言い換えることが、この会話のすべてです。

decision date と delivery date を区別する枠組みが、ここではいちばん実用的です。研究がいつ終わるかは分かりませんが、いつごろなら続けるか畳むかを判断できるのかは、たいてい言えます。そして製品側が実際に必要としているのも、たいていそれです。

レジスターについての判断を一つ付け加えます。I'd rather give you a date I believe than a date you want to hear のように相手を少し名指しする変形が出回っていますが、これはチームによって原則的に聞こえたり受動的攻撃に聞こえたりします。相手を文から外して自分についてだけ言う形が、どのチームでも安全です。上の表の五つ目の文がその形です。

状況7：非技術の利害関係者に不確実性を説明する

この場で失敗する仕方は二つあります。単純化しすぎて事実でないことを言うか、正確に言おうとして何も伝わらないか。

三つの規則がおおむねよく働きます。数字は一つだけ渡し、専門用語を抜き、失敗モードを必ず一緒に言います。

最後の文はこの聴衆にとってとくに重要です。非技術の利害関係者がいちばんよく見落とすのがどう間違うかという点です。失敗すれば止まるだろうと考えて計画を立てますが、言語モデルの失敗はたいていそうではありません。これを先に言っておかないと、あとで驚きが事故になります。

抜くべき単語の例を挙げるとこうなります。eval、harness、ablation、in-distribution、held-out、seed。これらの単語が悪いのではなく、この場では通じないというだけです。

状況8：まだ分からないと言いつつ次の段階も一緒に渡す

前の三つのかけらが、もっとも圧縮された形で必要になる瞬間です。会議中に突然質問が来て、答えが分からず、部屋には八人います。

四つ目の文がとくに有用です。即答を求められたときに、その要求を断らずに条件を返す形です。相手が推測でも必要だと言えば推測を渡せばよく、正確な答えが必要だと言えば時間が得られます。どちらにせよ、自分が言ったものの性格が明確になります。

最後の文はこの分野でよく必要になります。英語のベンチマーク結果を韓国語や日本語にそのまま移せない場合が多いのですが、その境界を先に引いておくと、あとで驚くことが減ります。

状況9：他人の実験結果に異議を出す

ここでの原則は一つに整理できます。結論に反論せず、条件を確認してください。

理由は単純です。条件の質問には答えがあり、攻撃には答えがありません。That's wrong に対しては防御しかできませんが、What was the baseline? には答えがあります。そして答える過程で、たいてい問題がひとりでに現れます。

One of us has a bug はこの分野でとくによく働く文です。二人の結果が違うときに、誰が間違っているのかを未定のまま残しつつ、原因があるという事実だけを確定します。相手が防御する理由がなくなるので、会話はすぐ技術的なほうへ移ります。

Before I push back も有用です。異議が来ることを先に知らせて、相手に準備する時間を渡します。ただしこの程度の予告が必要かどうかはチームによって違います。直接的な議論が既定値のチームでは不要な緩衝に感じられますし、逆に慎重なチームではこの一文が衝突を防ぎます。どちらか分からないなら、付けるほうが損は少ないです。

状況10：再現できないとき

再現の失敗はほぼ常に誰かのミスなのですが、その誰かが誰なのかはまだ分からない状態です。先に自分の側を疑う文で始めると会話は調査に流れ、相手の側を先に疑うと会話は防御に流れます。

That's probably on my end については、レジスターについての判断を一つ付け加えなければなりません。これは相手の面子を守りながら問題を提起する装置で、あとで相手側の問題だと分かっても誰も損をしません。ただしこの表現を習慣的に乱発すると、実際に自信がなさそうに見えることがあります。自己卑下を低く評価するチームではとくにそうです。再現の失敗のように原因が本当に不確実な状況では使い、明らかに相手のコードの問題であるときには使わないほうがよいです。

ヘッジの強さの目盛り

不確実性の表現をうまく使うには、強さを調節できなければなりません。以下はおおよその目盛りです。正確な確率に対応するものではなく、慣習的な印象に近いものです。

ここに規則を一つ付けます。一つの主張にヘッジは一つで十分です。I could be wrong, but I think maybe it might be the tokenizer のように四つ積むと主張そのものが消えて、聞いている人は内容の代わりに話し手の自信のなさを覚えます。

ただしこの判断はチームの文化によって変わります。婉曲さが既定値の組織では、ヘッジ二つが礼儀の下限ということもありえます。逆に直接的なエンジニアリングチームでは、一つでも多く感じられます。会議を二、三回観察すれば、そのチームの既定値が見えてきます。いちばん早い方法は、そのチームで信頼されているシニアを一人選んで基準線にすることです。

アメリカ式とイギリス式が分かれるところ

会議で実際に誤解を生むものがいくつかあります。

table という動詞は意味が正反対です。アメリカで Let's table this はあとに回そうという意味で、イギリスで to table an item は議題に上げようという意味です。会議の進行中に正反対に受け取られうる単語なので危険です。両方が混ざった会議では、Let's come back to this later や Let's add this to the agenda のように開いて言うのが安全です。

quite の強さが違います。アメリカで quite good はかなりよいという称賛に近く、イギリスで quite good は悪くはないという程度の生ぬるい評価として読まれることが多いです。評価結果を論評するときに誤解が生じやすい単語です。はっきり言いたいなら、quite を外して数字を言うほうがよいです。

momentarily も分かれます。アメリカではすぐにという意味で、イギリスでは少しの間という意味で使われる傾向があります。in a moment や briefly に替えれば誤解がありません。

Sorry の重さが違います。イギリスで Sorry は謝罪よりも会話の緩衝材に近く、ずっと頻繁に使われます。イギリスの同僚が謝罪を連発しているように見えても、それは謝罪ではありません。逆にアメリカの会社文化では、遅れを謝る代わりに Thanks for your patience に置き換えることを好む場合が多いです。ただしこれは会社文化の差が国の差と同じくらい大きいので、一般化はしません。

やらないほうがよいこと

結果を膨らませる文。この記事にはそういう例がありませんし、今後も入れません。理由は倫理的なものだけではありません。AI開発では、膨らませた数字はたいていその四半期のうちに検証されます。別のチームが同じ評価を回し、製品につなぎ、利用者が使います。膨らませた文の有効期限は、その数字が再現されるまでの時間だけです。

回帰を次の報告まで先延ばしにする。上と同じ理由で結局は表に出ますし、遅く出るほどその上に積まれた決定が多くなります。

It should work. エンジニアリングの英語では、この文は事実上テストしていないという合図として読まれます。should は報告ではなく予測だからです。代わりに、何をテストして何をテストしていないのかを言うほうがよいです。I tested the happy path and the empty input. I haven't tested concurrency.

単独で使う I'm not sure. 内部の状態だけを報告して、相手に何も残しません。あとに境界か次の段階のどちらか一つを付けるだけでまったく変わります。

条件のない数字。82とだけ言えば議事録には82だけが残り、その82は数週間後に根拠として引用されます。どのデータで何回の実行だったかは、そのとき誰も覚えていません。

質問で終える不確実性の報告。Let me know if you have any questions. で終えると、次の行動を相手に押しつけることになります。不確実性を報告するときは、自分が次の段階を提示して終えるほうがよいです。

他人の実験に結論で反論する。条件の確認が先です。条件を確認してからも異議が残るなら、そのとき結論を言えばよく、その時点での異議はずっと強くなります。

実戦の流れ：週次のモデルレビュー

前のかけらが実際の会議でどうつながるのかを見てみます。

PM:   So the new checkpoint is better, right? Can we ship Friday?

私:   Two caveats before the number.
      It is a single run, and it is on our internal set,
      so it is not comparable to the vendor numbers.
      With that said, we are up two points.
      Two points is inside the noise for this set,
      so I would not call it a win yet.

PM:   Okay. When will you know?

私:   What I can give you is a decision date, not a delivery date.
      Three more seeds is about two days of compute.
      By Wednesday I will know whether the gain is real.

PM:   And if it is real?

私:   Then there is a second question. I read twenty outputs by hand
      and some of them got longer without getting better.
      The metric moved, but I am not sure the task did.
      I would want a human check on a small sample before we ship.

同僚: I saw the opposite last week - my run showed a clear gain.

私:   That is interesting, because it contradicts mine.
      One of us has a bug. Before I push back,
      what was your baseline, and how many seeds?

同僚: Baseline was the March checkpoint. One seed.

私:   Okay, mine is against last month. That could be the whole difference.
      Can we get to the same number before we decide anything on top of it?

PM:   What do I tell leadership on Thursday?

私:   Short version: it looks promising, we do not know yet if it is real,
      and we will know by Wednesday.
      The failure mode to watch is longer answers that are not better ones.
      No decision needed from them this week.

この会話で私はよい知らせを一度も確定していません。それでも会議は詰まりませんでした。毎回、境界を引き、根拠を明かし、次の段階と時点を一緒に渡したからです。

今日すぐやってみること

表現をすべて覚える必要はありません。三つだけ自動で出るようにしてください。

1. 限界を前に置く一文: Two caveats before I give you the number. 数字を言う前に条件を先に置く習慣が、この記事全体でいちばん価値が大きいです。
2. 分からないを完成させる一文: I don't know yet. Here's what would tell us, and here's when. 境界と次の段階が一文に入っています。
3. 異議を条件確認に変える一文: I'm not doubting the number. I'm trying to work out what it's comparable to.

そして次の会議で一度だけ確認してみてください。自分が言った数字に条件を付けたか。付けていないなら、その数字はいま会議室で、自分が知っているより固いものとして流通しています。

続けて読む

• 状況がなくても英語が伸びる方法 — 上の状況を実際の会議の前に一人で回してみる方法。
• リーダーボードとベンチマークの読み方 — どの条件を付けるべきか、その条件一覧の根拠。
• AIベンチマーク比較 — 会議で引用する数値の出典と条件を自分で確認できます。
• ハーネスエンジニアリングRPG — 評価者のボトルネックとリワードハッキングが実際にどう生じるのかをシミュレーションで体験します。
• 英会話練習 — 上の会話の流れを声に出して練習します。