halcight · システム設計と AI コーディング

AI 時代のエンジニア採用

Fri, 13 Nov 2026 00:00:00 GMT

これまでの技術面接は、コーディング能力を中心にしてきました。候補者がどの言語やフレームワークに詳しいか、ホワイトボードでアルゴリズム問題の解法を書けるか、といった点です。

AI の時代には、これはもう有効な基準ではありません。ある言語に詳しくなくても、AI の力を借りて価値のあるプロダクトを届けることができます。

より注目すべきなのは、次の 2 つの能力です。

1 つ目はシステム全体の理解です。完成したシステムにはどんな部分が必要か、それぞれがどう連携するか、リリース後に正常に動いていることをどう確かめるか。この理解がなければ、AI が出す設計案を評価できません。

2 つ目は知的好奇心です。新しい知識、特に AI の分野を自分から追いかけること。ツールやモデルの変化は速く、今日のベストプラクティスが半年後には古くなっているかもしれません。新しい技術を学び、試し、振り返り続けるかどうかは、エンジニアとしての長期的な成長に直接影響します。

いま最も重要な 6 つの能力

1. AI に意図を正確に伝える。 AI は与えられた情報をもとにしか動けません。目標、制約、完了の基準、何が決まっていて何が決まっていないか。これらを明確に伝えるほど、成果物は期待に近づきます。伝え方があいまいだと、もっともらしく見えて実は要件から外れた結果になりがちです。

2. AI の意図を理解する。 AI が計画やコードを返してきたとき、エンジニアはその考え方を読み取れなければなりません。要件をどう理解したのか、どんな前提を置いたのか、どこが推測なのか。AI の誤解に気づけることは、同じコードを自分で書けることよりも重要です。

3. あいまいな目標から、システムの姿を見通す。 要件は初めのうちはたいていあいまいです。優れたエンジニアは手を動かす前に、システムについての初期の見立てを持ちます。おおよそどんな部分で構成され、どこが難しくなりそうか。そして新しい情報に応じて修正していきます。この見立てがあって初めて、AI の設計案が正しい方向に向かっているかを判断できます。（私のやり方は今のシステムの設計の仕方にまとめています。）

4. テストを設計する。 コードがどれだけ速く生成されても、検証は省けません。どこを必ずテストするか、どんな方法を使うか、テストが検証したい振る舞いを本当にカバーしているか。いずれもエンジニアの判断が必要です。

5. 監視を設計する。 リリース前はテストが主要な振る舞いを検証して不具合のリスクを下げ、リリース後は監視が稼働状況を見守って異常を早く見つけます。どちらもシステムが常に正しいことを保証するものではありませんが、どちらも欠かせません。どんなログやメトリクスが必要か、障害が起きたときに誰がどれくらいの時間で気づくか。これらは障害の後で付け足すのではなく、設計の段階で考えておくべきです。

6. AI のワークフローを管理する。 agent が 1 つでも複数でも、作業をどう分けるか、成果物をどうレビューするか、文脈をどう保つか、自分がボトルネックにならないためにどうするか。それ自体がエンジニアリングの能力です。（私のやり方は十数個の AI agent を同時に動かす方法にまとめています。）

面接でどう見極めるか

grill-me で判断力と伝える力を見る

grill-me は AI のスキルの 1 つです。計画を渡すと、AI は判断どうしの依存関係に沿って何回かに分けて質問し、それぞれに推奨の回答を添えます。すべての判断に結論が出るまで続きます。

面接では、候補者にあいまいな要件を渡し、grill-me を使って AI と対話しながら、明確な設計案にまとめてもらいます。対話を始める前に、システムの境界、主な前提、まだ検証が必要な点を簡単に説明してもらいます。対話が終わったら、どの判断が変わったか、それはなぜかを説明してもらいます。このステップで見るのは 3 つ目の能力、つまり AI が提案する前に、候補者自身がどう判断していたかです。

対話の間、面接官は次の 2 点に注目します。

自分で判断しているか。 基準は AI に反対するかどうかではありません。それぞれの提案を受け入れた理由、退けた理由を説明できるか、それをどう検証するつもりかです。AI に頼りきっている人は、AI が間違えたときにも気づきにくくなります。
正確に伝えているか。 回答は明確か、必要な文脈や理由を添えているか。AI が誤解したときに、それに気づいて正せるか。

ホワイトボード問題と比べて、こちらのほうが候補者の日々の仕事にずっと近いやり方です。

システム設計：テストと監視を自分から考えているか

システム設計の問題は今も有効ですが、見るべき点は変わりました。コンポーネントとデータの流れを図にすることは、AI にもできます。より注目すべきなのは、候補者が言われなくても、システムをどうテストするか、リリース後にどう監視するか、障害にどう気づくかに触れるかどうかです。触れたこと自体は手がかりにすぎません。具体的な障害のシナリオを 1 つ挙げて掘り下げましょう。テストはその問題をどう捉えるか、本番ではどのシグナルで気づくか、誰が対応するか。こうした回答は、候補者がシステム全体を理解しているかを判断する材料になります。ただし、1 つの場面への回答だけで結論は出せません。

日頃 AI agent をどう管理しているか

最後に、普段 AI をどう使って仕事をしているかを聞きます。同時にいくつの agent を使うか、どう分担させるか、成果物をどうレビューするか、どんな問題にぶつかったか、最近どんな新しいツールを試したか、なぜ使い続けているのか、あるいは使うのをやめたのか。

具体的な経験や教訓は、さらに質問を重ねるための材料です。ただし、話がなめらかかどうかだけで実力を判断することはできません。この質問は知的好奇心を見るものでもあります。その人が最近何を試しているかは、履歴書のスキル一覧よりも多くを語ります。

公平さを保つ

面接する側は、全員に同じ AI ツール、モデル、アカウントを用意し、必要なスキルをあらかじめ入れておき、環境に慣れる時間を設けたうえで、課題、制限時間、評価基準をそろえるべきです。agent の数や有料ツールの使用経験では加点しません。こうしたツールを使う機会がなかった候補者でも、その場の課題を通じて、仕事の組み立て方、結果の検証の仕方、新しいやり方の学び方を示すことができます。

おわりに

AI の時代に求められるのは、いちばん速くコードを書く人ではありません。AI と協力して、あいまいな目標をテストと監視のできる完全なシステムに仕上げ、学び続けるエンジニアです。

十数個の AI agent を同時に動かす方法

Sat, 07 Nov 2026 00:00:00 GMT

私は 8 つのプロジェクトを並行して進めています。多いときには 17 個の agent が動いています。

管理には Herdr を使っています。コーディング agent 向けのターミナルワークスペースで、agent ごとにペインが 1 つあり、それぞれが作業中・ブロック中・完了・待機中のどれなのかを Herdr が判別します。agent 同士で互いの出力を読んだり、メッセージを送り合ったりすることもできます。

ただ、ツールが解決するのは「見えること」までです。本当のボトルネックは私の注意力です。ペインを切り替えるたびに、そのプロジェクトの文脈を頭の中で組み立て直さなければなりません。agent が増えるほど、私自身がシステム全体でいちばん遅い部分になっていきます。

そこで、構造を 2 段に分け、さらに私の代わりに巡回する agent を 1 つ置きました。

メイン agent とは深く話し、全員は浅く読む

私がメイン agent と深くすり合わせる
オーケストレーターが読む・通知する・中継する
私への通知
メイン agent がサブ agent を起動し、受け入れ確認する

2 種類の会話が同時に進みます。

私とメイン agent：深い対話。 各プロジェクトには、そのプロジェクトの文脈をすべて持つメイン agent が 1 つあります。設計、計画、未決事項は、このメイン agent と直接すり合わせます。
オーケストレーターと全 agent：浅い読み取り。 オーケストレーターはどのプロジェクトも担当しません。5 分ごとに全 agent の最新の出力を読み、私の対応が必要なことだけを報告します。

これで、プロジェクトを 1 つずつ切り替えなくても全体を把握できます。深く入る必要があるときは、1 つのプロジェクトに入り、1 つのメイン agent とだけ話します。

構造は 2 段まで。 メイン agent はサブ agent を起動できます。レビュー担当、1 つの PR の実装担当、並行して動く複数のチームなどです。サブ agent はさらに下の段を起動しません。そのため、どの agent も文脈を持つメイン agent から 1 段以内にあり、成果物はメイン agent が受け入れ確認をします。これ以上深くすると責任の境界があいまいになり、文脈も段ごとに失われていきます。

4 つの役割

私：各メイン agent と方向を決め、私の判断が必要な問題、承認ダイアログ、Web 画面で私にしかできない操作に対応します。クラウドリソースへの書き込みやインフラの変更といったリスクの高い操作は、私自身が承認します。
メイン agent： 1 つのプロジェクトについて、文脈、計画、PR、現在の状態を記録するファイルに責任を持ちます。自分が出した PR は、CI、レビューコメント、コンフリクトを含めてマージまで責任を持ちます。サブ agent を起動し、その成果物を受け入れ確認します。
サブ agent： メイン agent のために、範囲のはっきりしたタスクを 1 つこなします。PR の実装、設計のレビュー、1 回分のクリーンアップなどです。報告先はメイン agent で、終わったら閉じます。
オーケストレーター： プロジェクトも PR も担当しません。5 分ごとに全 agent を巡回し、私の対応が必要なことを報告し、作業が重なっている双方に通知し、私の回答をそのまま中継します。

5 分ごと：先に重なり、次に要対応

オーケストレーターは毎回同じ順序で動きます。重なりのチェック、要対応のチェック、そして報告です。

この 2 つのチェックが、この仕組みの中心です。agent が増えると、よくある問題は 1 つの agent の誤りではありません。2 つの agent がそれぞれ正しく動いていても、合わさると衝突すること。あるいは、ある agent が私を待って止まっているのに、私がそれに気づかないことです。

重なりのチェック：1 つの領域に 1 つの方向

メイン agent 同士は、互いの文脈を見られません。

重なりとは、2 つの agent が両方とも変更または決定している 1 つの領域のことです。モジュール、ドキュメントやアーキテクチャ決定記録（ADR）、インターフェースの取り決め、PR、デプロイなどです。オーケストレーターはパスだけでなく意味で照合します。たとえば services/foo と docs/spec/foo は同じ領域です。

重なりを見つけると、オーケストレーターは双方に同時に通知します。どちらかがその領域を再び変更する前に、双方が相手の計画を知り、合意していなければなりません。

次のものは重なりとはみなしません。

メイン agent と自分のサブ agent（同じタスク指示を共有しているため）
読むだけ、またはレビューするだけの agent
一方の変更がすでにマージされている領域

24 時間以内に通知済みで、その後新しい変更がない組み合わせには、再度通知しません。

例：2 つのフロントエンド PR が同じファイルを変更

プロジェクト B と E は、同じフロントエンドのリポジトリでそれぞれ別のアプリを開発しています。

前日、オーケストレーターはリポジトリの共有部分（コンポーネントライブラリ、モックのバックエンド、インターフェースの取り決め）について双方に初めて通知し、どちらがどの共有ファイルを変更してよいかで合意しました。
10:11、プロジェクト E の PR が開発ガイドとロックファイルを変更していて、次にマージされる予定でした。プロジェクト B が新しく出した骨組みの PR も、同じ 2 つのファイルを変更していました。オーケストレーターの判断は、方向は一致している（別のアプリ）が、後からマージする側がコンフリクトする、というものでした。双方に通知し、この組み合わせを記録しました。
10:12、2 つの agent が直接やりとりし、E を先にマージして B が後でリベースすることで合意しました。それぞれ状態ファイルに記録しました。
10:16、E の PR がマージされ、開発環境にデプロイされました。
10:36、B のリベースが完了しました。開発ガイドには双方の変更が残り、ロックファイルは変化なし。型チェック、lint、テスト、ビルドはすべて通りました。

この間、私には何も聞かれませんでした。報告に「通知済み……方向は一致」という 1 行が加わっただけです。

プロジェクト B への通知はおおよそ次のとおりです。プロジェクト E には立場を入れ替えた同じ内容が届きました。

重なりのチェック（オーケストレーターより）：あなたとプロジェクト E は、フロントエンドのリポジトリの共有ファイル（開発ガイドとロックファイル）を両方とも変更しています。
- あなた：骨組みの PR がこの 2 つのファイルを変更しています。
- 相手：同じ 2 つのファイルを変更する PR が、まもなくマージされます。
- 判断：方向は一致（別のアプリ）。ただし、後からマージする PR はコンフリクトします。
これらのファイルを再び変更する前に、計画を 1 通のメッセージで相手に送り、返事を読み、どちらがリベースするかを決めて、その合意を状態ファイルに書いてください。
合意できない場合、またはこれが人間の決めるべき選択である場合は、これらのファイルの変更を止め、返信でそう伝えてください。

大事なのは最後の一文です。合意できない衝突や、本来私が決めるべきことは、agent 同士で勝手に片づけられません。その作業は止まり、「あなたが対応すべき衝突」として私の報告に上がってきます。

要対応のチェック：何を「私の対応が必要」とするか

重なりのチェックの後、オーケストレーターは agent ごとに、私を待っているかどうかを判断します。鍵は「私の対応が必要」を明確に定義することです。広すぎると報告がノイズだらけになり、私はすぐに読まなくなります。狭すぎると、本当に止まっている agent を見落とします。

対応が必要：

承認や質問のダイアログで止まっている。報告にはダイアログの原文を引用する。
最後の返答が私に判断・選択・操作を求めていて、まだ答えがない。権限チェックで拒否された操作も含む。
自分では直せない失敗を報告している。
ホストの異常：ディスクの空きが 30 GiB 未満、または Docker が応答しない。全 agent のビルドと E2E テストがこの 2 つに依存している。
引き継ぎを監視するプロセスが 10 分以上ポーリングしていない。

対応は不要：

チームメイトの承認や CI を待っている。「待ち」の行に入れる。
agent の入力欄に残っている文字。私がまだ送っていない入力か提案であって、質問ではない。
中継した回答ですでに解決した質問。

対応不要の agent は、作業中・待ち・待機中のどれか 1 行にだけ入ります。待機中の agent には直近の作業領域を書き添えるので、新しいタスクを渡すか閉じるかを判断できます。

報告

報告の形はいつも同じです。最初に重なり、次に私の対応が必要なこと、最後に作業中・待ち・待機中を 1 行ずつ。次はある日の午前の報告で、名前は置き換えてあります。

重なり：あなたの対応が必要な衝突はありません。通知済み：フロントエンドのリポジトリの開発ガイドとロックファイル（プロジェクト B ↔ プロジェクト E、方向は一致）。

対応が必要：
1. プロジェクト B（新しいアプリの骨組み）：フロントエンドのリポジトリに、社内 npm パッケージの読み取り権限を付与してください。
2. プロジェクト A（性能）：サービスを 1 vCPU に下げるインフラ変更。残しますか、閉じますか？

作業中：プロジェクト B の実装担当（アプリの骨組み）、プロジェクト C のチーム c（E2E シナリオ 16 本）
待ち：  プロジェクト C のチーム a（承認 1/2）、プロジェクト D（承認 1/2）
待機中：雑務（Docker とディスクの整理）、テストカバレッジの監査
ホスト：空き 313 GiB、Docker 正常

数秒で読み終わり、自分の作業に戻れます。

その日の午前の 3 件の通知

09:45 Docker が止まっていて、プロジェクト C のチーム c が E2E シナリオ 16 本を実行できず、メイン agent がダイアログで尋ねてきました。私が「Docker を起動」を選ぶと、オーケストレーターが起動してダイアログに回答しました。シナリオが流れ、チーム c が PR を出しました。
09:53 プロジェクト B が、GitHub の Web 画面で私にしかできない操作を必要としていました。フロントエンドのリポジトリに、社内パッケージの読み取り権限を付与することです。設定を終えると、オーケストレーターが「完了」と中継し、プロジェクト B はすぐに最初のフロントエンド PR に取りかかりました。
09:53 プロジェクト A が朝の起動時の負荷を測定し終え、サービスを 1 vCPU に下げるインフラ変更を残すか閉じるかを尋ねてきました。「残して着手」と答えると、数分後に PR が出ました。Terraform plan には想定どおりの変更だけが出ていました。

オーケストレーターがいなければ、Docker が止まっていることに気づくのは、たまたまプロジェクト C を見たときになっていたはずです。

注意力は判断のために残す

この仕組みで大事なのは、agent の数ではなく、注意力の配分です。

方向やトレードオフを決められるのは私だけなので、メイン agent とは深く話す。
「誰が私を待っているか」「誰と誰がぶつかっているか」は明確に定義でき、定期的に確認できるので、オーケストレーターに任せる。
2 段の構造によって、どの agent の成果物も、文脈を持つメイン agent が受け入れ確認する。

agent はいくつでも並行して動かせますが、判断する人は 1 人だけです。その人の注意力は判断のために残し、それ以外は仕組みに任せます。

日本の IT は遅れているのか

Wed, 04 Nov 2026 00:00:00 GMT

日本の IT は遅れている、とよく言われます。私の答えは、イエスでもあり、ノーでもあります。

優秀なエンジニアはいる

日本のエンジニアが IT 業界にもたらしたものは少なくありません。QR コードはデンソーウェーブの原昌宏さんが開発を率い、1994 年に発表されました。Ruby は松本行弘さんが 1995 年に公開しました。ソフトウェア開発のリーンやかんばんも、トヨタ生産方式から生まれたものです。日本に優秀なエンジニアがいなかったことはありません。

もちろん、こうした例から平均的な水準は分かりません。日本の IT エンジニアの平均的な水準は、やはりアメリカや中国に及ばないと私は思います。大学教育の影響も大きく、ソフトウェア工学という分野が日本では十分に広まっておらず、重視もされていません。ただ、問題の核心はそこではないと思います。アメリカにも、別の専攻から転身してきたエンジニアは少なくありません。出身の専攻が彼らの妨げにはなっていません。

問題は会社の仕組み

本当の問題は、会社の仕組みが時代の変化に追いついていないことです。

これはデータにも表れています。IPA（情報処理推進機構）の調査によると、2020 年の時点で日本の IT 人材の 73.6% は IT 企業に所属していて、ほかの業種の企業にいるのは 4 分の 1 ほどです。アメリカは逆で、2021 年に IT 企業に所属していたのは 35.1% にすぎず、多くは IT を使う側の企業にいます。つまり日本の多くの会社は自前のエンジニアチームを持たず、システムを SIer に任せ、さらに多重の下請けに出すことも珍しくありません。決める人とコードを書く人の距離が遠く、エンジニアがプロダクトそのものに関わるのは難しくなります。

2026 年 11 月 2 日、GMO インターネットグループは「お名前.com デスクトップクラウド」への不正アクセスについて記者会見を開きました。攻撃者は顧客が使うリモートデスクトップのサーバーから入り込み、管理者アカウントを盗みました。グループのセキュリティ会社は、2024 年の時点でシステムの問題を指摘していました。ただ、私の印象に強く残ったのはセキュリティの失敗そのものではありません。会見の中の一場面です。担当の責任者が記者に説明を始めたところで、グループの代表がそれを遮り、上着のボタンが開いていることを注意したのです。「お詫びをしているのにボタン開けてどうするんだ」と。

Satya Nadella や Elon Musk が、人前でも人のいないところでも、ボタンのことで部下の話を遮る姿は想像しにくいでしょう。多くの人はおかしいと感じるはずですが、本人は何も問題だと思っていないようでした。私は、これこそ日本の多くの IT 企業が遅れている理由だと考えます。権力を軸にした厳しい上下関係は、ソフトウェア開発に必要な、開かれた対等な環境と相容れないのです。

ここで言う上下関係は、仕事上のレポートラインのことではありません。マイクロソフトや Amazon にももちろん階層やレポートラインはありますが、それは仕事の分担であって、命令の階層ではありません。そこでは多くのプロジェクトがボトムアップで生まれます。日本の会社では、こうしたボトムアップの流れはあまり見られません。根本的な原因が日本の社会や文化にあるのかどうかは、この記事の範囲を超えるので、ここでは掘り下げません。確かなのは、強い権力の階層の下では、複雑なソフトウェア開発はうまく進まないということです。

理性的な議論や、議論で知識を確かめ合うことには、対等な環境が欠かせません。Google の Project Aristotle は 180 のチームを調べ、それらのチームでは、成果を左右する 5 つの要素のうち、最も重要なのは心理的安全性だと結論づけました。ミスを認めても、質問や新しいアイデアを出しても、恥をかかされたり罰せられたりしないとメンバーが信じられることです。多様性も同じように大切です。研究をまとめた Harvard Business Review の記事によると、多様なチームは事実をより重視し、事実を見直すことが多く、事実の誤りも少なくなります。どれも、日本の多くの会社に欠けているものです。

リーダーは技術を知っているか

もう一つの違いは、チームを率いる人が技術に詳しいかどうかです。日本の IT 企業では、プロジェクトマネージャー（PM）が階層の上のほうにいることが多いようです。アメリカや中国の IT 企業は違います。マイクロソフトでは、コードを書くエンジニアになりたい PM（プログラムマネージャー）は多く見ましたが、PM になりたいエンジニアはほとんどいませんでした。チームのマネージャーも、多くはエンジニア出身です。

責任をどう考えるか

責任のとらえ方も違います。日本の多くの会社では、決めるときの大事な基準の一つが、組織が責任を負わずに済むかどうかです。「こうしておけば、何かあっても責任を問われない」。気持ちは分かりますが、アメリカの IT 企業でこういう判断基準を感じたことはほとんどありません。

日本が得意なこと

逆に、日本の得意な分野を見てみます。文化産業では、一人ひとりの貢献が大きな意味を持ちます。自動車のような重工業では、チームがどれだけ厳密にルールを守るかが決め手になります。ところがソフトウェア開発に必要なのは、そのどちらでもない第三のもの、つまり対等な議論と、素早く試して改善を繰り返すことです。

日本の IT にも、個人や小さなチームによる革新はあります。たとえば Preferred Networks のディープラーニングフレームワーク Chainer は、2015 年に define-by-run という書き方を打ち出し、この考え方はその後、研究の世界に広く取り入れられました。それでも業界全体が前に進むには、チームの考え方が変わる必要があります。

日本の IT 企業はどうすべきか

一つ目に、アメリカのトップクラスのテック企業に学び、自前のエンジニアチームをつくって外注を減らすことです。システムは会社の中核の力であって、すべてを他人に任せるべきではありません。エンジニアが社内にいてこそ、事業やプロダクトに近づき、結果に責任を持てます。

二つ目に、海外の高度な人材を積極的に迎え入れること。そして、こう理解しておくことです。高い給料で聡明な人を雇うのは、その人にやり方を指示するためではなく、その人にやり方を教えてもらうためだと。

三つ目に、そして最も大切なのは、開かれた対等な職場を受け入れ、権力の階層を弱めることです。職場では仕事の中身だけに目を向けるべきで、GMO グループの代表のように、お詫びの会見でボタンのような取るに足らないことに目を向けるべきではありません。

四つ目に、技術を分かっている人に技術の判断を任せることです。エンジニアにマネージャーと並ぶキャリアパスを用意し、ベテランのエンジニアがマネジメントに移らなくても、それに見合う職位と待遇を得られるようにします。エンジニアリングチームを率いる人も、できればエンジニア出身であるべきです。

五つ目に、問題が起きたら、個人を責めずに振り返ることです。Google の SRE では、これを blameless postmortem と呼びます。振り返りでは事故の原因だけを探し、どの個人やチームも責めず、関わった全員が善意で、その時点で分かっていたことに基づいて正しく行動したと考えます。直すのは仕組みやプロセスであって、人ではありません。責任を問われる不安がなくなってはじめて、判断の基準は「何が一番よいか」に戻ります。「どうすれば一番失敗しないか」ではなく。

これは非難のために書いたのではありません。改善の余地がどこにあるかを示したかったのです。