コミュニケーション on Feature Branch Tech Blog

昔は曖昧だと止まった。今は曖昧でも進む。だからAI時代の方が危ない

Sun, 29 Mar 2026 09:00:00 +0900

昔は曖昧だと止まった。今は曖昧でも進む。だからAI時代の方が危ない

はじめに

AIを使うと、仕事が前に進む速度は確かに上がります。

コードのたたき台を作る。文章を整理する。調査の出発点を作る。ひと昔前なら半日かかったことが、数分で返ってくることもあります。

そこは本当に便利です。

でも、その便利さの裏に少し怖さがあります。

昔、ある自動車メーカー向けのCAD関連の仕事で、車体がたわんだときに、ある部品の曲面が別の部品にどう影響するかを計算する処理を作ったことがありました。

CGっぽく言うと、あるボディパネルの影が別のパネルのどこに落ちるか、みたいな計算です。担当の数学者が提示した式を、私がコンピュータで動く形に落とし込んでいました。

ところが、どうしても収束しないケースが出ました。

当然、最初は自分の実装ミスを疑いました。でも調べていくと、実装ではなく、渡されていた計算式のほうに問題があったんです。修正案とエビデンスをそろえて担当数学者に確認し、最終的に必要な機能を満たす形に直しました。

CGなら、ある程度それっぽく見えれば許される場面もあるかもしれません。でも、自動車の部品ではそうはいきません。人を乗せて走るものだからです。

この件を振り返って今強く思うのは、昔の開発は、曖昧さや不具合があると途中で止まるしかなかった、ということです。

人が確認に入る。検証で矛盾が見つかる。計算が収束しない。つまり、曖昧さが早い段階で露出しやすかった。

ところが今は、AIがそこをそれっぽく埋めて前へ進めてしまいます。止まらない。速い。しかも、見た目もそれなりに整っている。

だから私は、AI時代は楽になった部分もある一方で、仕様を伝える難しさはむしろ上がったと思っています。

1. 昔は、曖昧さがあると止まった

昔の開発環境は、今のように気軽ではありませんでした。

計算資源が限られていた
実行確認の回数も少なかった
一回の手戻りが重かった

そんな環境では、「まあ、だいたいこういう意味だろう」で進めるのは危険でした。

数学者や物理学者が考えた内容を、そのまま機械が理解してくれるわけではありません。考え方を整理し、前提を確認し、条件を明文化し、コンピュータが処理できる形に落とし込む必要がありました。

たとえば、次のような点が曖昧なままだと、どこかで必ず詰まります。

何を求めたいのか
どこまでの誤差を許すのか
想定外の入力が来たらどうするのか
何をもって正しいと判断するのか

昔は、こういう曖昧さがあるとごまかしが利きませんでした。

計算結果が合わない。検証で再現しない。レビューで説明できない。曖昧な部分が、そのまま手戻りや停止として返ってきたのです。

しかも重要なのは、通訳する側が単に受け取って流すだけでは足りなかったことです。成立しているか、破綻しないか、要求を満たすかまで見ないと仕事になりませんでした。

今振り返ると、あの時代に必要だったのは「賢い人の頭の中にあるものを、曖昧さの少ない仕事の言葉に変えること」であり、同時に「それが本当に成り立つかを検証すること」でもありました。

2. 今は、曖昧でも進んでしまう

今はそこにAIが加わりました。

AIは便利です。ですが、読心術は使えません。

こちらが言っていない前提は、本来分からないはずです。それでもAIは、足りない部分を推測して、それっぽく補い、もっともらしい答えを返します。

たとえば、こう頼んだとします。

1

この画面のバグを直して

これでもAIは何かしら返してきます。

でも、本当に必要な情報はかなり抜けています。

どの画面か
何がバグなのか
期待する挙動は何か
触ってよい範囲はどこまでか
何を確認したら完了なのか

人間の実装者なら、「情報が足りません」と聞き返してくれるかもしれません。ところがAIは、そこを自分で埋めて進みがちです。

ここが便利さであり、同時に危なさでもあります。

昔は曖昧だと止まりました。
今は曖昧でも進みます。

進むこと自体は良いのですが、正しい方向に進んでいるとは限りません。

しかもAIは速いので、ズレた前提のまま成果物が量産されやすい。これが人間相手より厄介だと感じる理由です。

3. 危ないのは「間違うこと」より「間違ったまま進むこと」

人間もAIも間違えます。そこ自体は新しい話ではありません。

でもAI時代に少し怖いのは、間違いが露出しにくいことです。

コンパイルエラーのように止まってくれれば気づけます。レビューで「この前提は違います」と返ってくれば立て直せます。

ところがAIは、ある程度もっともらしい文章、コード、設計案を返してきます。見た目が整っているので、「とりあえず前に進んだ感」が出てしまう。

私は、ここにAI時代の落とし穴があると思っています。

危ないのは、AIが間違うことそのものではありません。曖昧な依頼でも、止まらず、確認もせず、もっともらしく前へ進んでしまうことです。

昔の不便な環境には、皮肉にも安全装置がありました。曖昧さや不具合があると、収束しない、説明できない、検証で落ちるといった形で止まりやすかったからです。

今は便利になったぶん、その安全装置が弱くなったとも言えます。

4. では、何が必要なのか

ここで必要になるのは、魔法のようなプロンプトではないと思っています。

必要なのは、昔からある基本です。曖昧な仕事を、相手に渡せる仕様へ変換することです。

2ターン設計で精度を上げる：VSCode×Codexのやりとり術

Thu, 22 Jan 2026 10:00:00 +0900

はじめに

「VSCodeからCodexにお願いしたけど、意図とズレた」――そんな経験はありませんか。私自身、短く書くと精度が落ち、長く書くと伝える内容が散らばることがありました。

そこで効果があったのが2ターン設計です。1回目で前提を確認し、2回目で実行に移す。たったそれだけで、精度と納得感が上がりました。この記事では、VSCode×Codexで使える「2ターンの型」を整理します。

1. なぜ1回でうまくいかないのか

LLMは文脈が不足していると、良い推測はしても本当に欲しい答えに辿り着けないことがあります。公式のプロンプト指針でも「目的・制約・期待する出力」を明確に伝えることが推奨されています¹²。

つまり、1回目の指示で「必要な前提が足りているか」を確かめるだけで、2回目の成功率が大きく上がります。

2. 2ターン設計の全体像

2ターン設計は、**確認（Turn 1）→実行（Turn 2）**の流れです。会話の段階を明確にするだけで、やりとりが安定します。

flowchart LR
 A[Turn 1: 調査・前提確認] --> B[Turn 2: 実装・反映]

Turn 1: 調査・前提確認

このターンでは、**「何を、どこまで、どういう形で」**を固めます。足りない情報があれば質問してもらい、必要な前提を揃えるのが目的です。質問してから進めるスタイルは公式例でも推奨されています³。

Turn 2: 実装・反映

Turn 1で前提が揃ったら、実装・修正・整理などを依頼します。ここでは作業のゴールと受け入れ条件が明確になっていることが大事です。

3. Turn 1のテンプレ（そのまま使える）

短くてもよいので、次の項目を伝えると迷いが減ります。

目的
変更範囲
期待する出力
制約（触らない場所、守るルール）
参照してほしいファイル

実際のテンプレはこんな感じです。

1
2
3
4
5
6
7


目的: 画面の表示崩れを直したい
変更範囲: @src/pages/order-detail/ だけ
期待出力: レイアウトが崩れずに表示されること
制約: UIの文言は変更しない
参照: @src/pages/order-detail/index.tsx

まず原因を調査して、必要なら質問してください。

ポイントは「まず調査して」と先にフェーズを指定することです。これだけで、いきなり修正を始めるリスクが減ります。

4. Turn 2のテンプレ（承認してから実行）

Turn 2では「OK、やってください」を明示します。明確な実行依頼が推奨されることは公式のベストプラクティスでも触れられています¹²。

1
2
3
4
5


ありがとうございます。修正案で進めてください。

- 変更は最小限で
- テストは不要
- 差分を最後にまとめてください

この形式だと、実装範囲が安定し、仕上がりの確認も楽になります。

多様なチームを動かす「共通言語」としてのロジック

Sat, 20 Dec 2025 10:00:00 +0900

多様なチームを動かす「共通言語」としてのロジック

〜プロジェクトを通して再認識した、コミュニケーションの基礎〜

0. はじめに

現在のプロジェクトは、「国籍・会社・業務経験」がバラバラな混成チームです。そこで痛感したのは、これまでの阿吽（あうん）の呼吸」や「言わなくてもわかるだろう」という甘えは、多様なメンバー間ではリスクでしかないということです。

背景が違う者同士が最短距離で成果を出すために必要なのは、感情やニュアンスではなく 「ロジック（論理）」という共通言語 でした。今回は、私が現場で学び直したコミュニケーションの3つの基礎を共有します。

1. 相手の期待値を把握する（ゴールの定義）

コミュニケーションの失敗の多くは、「何を話すか」ではなく 「相手が何を求めているか」のズレ から起こります。

期待値を外さないための3ステップ

目的の確認: 相手は「ただの報告」が欲しいのか、「具体的なアドバイス」が欲しいのか、あるいは「意思決定」をしてほしいのかを見極める。
着地点の共有: 「この話が終わった時、どういう状態になっていればよいか」を合意してから本題に入る。
時間軸の把握: 「今すぐ結論が必要」なのか、「時間をかけて検討したい」のか、スピード感の期待値を合わせる。

事例：目的を持つ話し方

NG：「この改修、なるはやでいい感じにお願い」
結果：1週間後に「期待と全く違うもの」が出てくる
OK：「目的は明朝のデモ用。範囲はログイン画面のみ。精度はモックレベルでOK。今日の18時に一度見せて」
Point：「何を・いつまでに・どのレベルで」 を定義する。ロジカルシンキングの基本「目的の明確化」を徹底します。

2. 質問を正しく理解する（問いの構造化）

相手の言葉を自分の勝手な解釈で受け取らず、論点を整理して打ち返します。

事例：質問の型を把握した上で話す

不透明なやり取り
メンバー: 「仕様、A案とB案どちらがいいですかね？」
PL: 「Aの方がユーザーには親切かな。あ、でもBの方が実装は楽だよね。検討してみて。」
結果: メンバーは「判断」を求めているのに、PLが「感想」を返したため、意思決定が停滞する。

ロジックによる構造化
PL: 「 『どちらにするか、今、私が判断すべきか？』 という質問ですね。結論、Aで行きます。」
理由: 「今回の最優先事項が『UX向上』だからです。工数増はスケジュール側で私が吸収します。」
Point: 相手の問いを「事実の確認」なのか「意思決定の依頼」なのか構造的に捉える。

3. Talk Straight で話す（結論と根拠の提示）

背景が違うからこそ、遠回しな表現は「ノイズ」になります。まず結論から話すことが、チームに対する最大の誠実さです。

事例：進捗確認への回答

NG（状況が見えない） 「あー、API連携の件ですね。一応メールはしたんですけど、時差もあって返信がまだで。マニュアルも読んだんですが、仕様が特殊みたいで……。まあ、週明けにはなんとか……」

OK（Talk Straight）
「結論から言うと、API連携の実装は現在ストップしています。」

イシュー: 認証認可の仕様が不明確であること。
答え: 現状では実装不可能です。
理由: 先方からの技術回答が届かない限り、セキュリティ要件を満たせないため。
事実と判断: 昨夜から回答待ち状態です。経験上、回答に3日はかかるため、その間は別タスクを優先します。

Point：結論から話す (PREP法) 結論（Point）→ 理由（Reason）→ 具体例（Example）→ 結論（Point）の順で構成し、相手の脳の負担を減らします。