はじめに
2026年4月22日に Sansan の Eight 主催（特別協力: connpass／株式会社ビープラウド）で開催された TechLead Conference 2026 powered by connpass に参加してきました。
テーマは「AI時代に、テックリードは何を変え、何を守るのか」。和田卓人（t_wada）氏の基調セッションを軸に、Sansan CTO 笹川裕人氏、Postman 草薙昭彦氏、レクター 広木大地氏、寺田学氏、澁井雄介氏（LayerX）、逆瀬川氏など、第一線の登壇者が集まりました。
当日聴講したセッションの中から、テックリードおよびエンジニアリングマネージャーにとって重要だと考えた点をメモとして整理しました。
記録ベースのため、文章のつながりに不自然な箇所がありますが、ご了承ください。
💡本レポートのキーメッセージ
「AI は増幅器（Amplifier）である」——基礎力のある組織はさらに強くなり、基礎力のない組織はその弱さが拡大されて淘汰される。各セッションの論点はすべて、この一言に収束します。私たちが問うべきは「AI をどう使うか」ではなく、「増幅される側の土台(組織、チーム、エンジニア)をいかに強化するか」です。
AI時代のエンジニアリング原則 — 変わるもの、変わらないもの
オープニングは t_wada 氏による基調セッション。AI がコードを書くようになった現在地を、「変わったこと」「変わらなかったこと」「わかったこと」 の3つで整理する構成でした。
変わったこと
- AI がコードを書くようになり、人間は 確認と承認 に注力する役割にシフトした
- 要件定義のフォーマットが変わった。
Excelではなく テキストベース、コードと同じリポジトリに設計書を置く運用が増えてきた - 仮説検証フェーズでは、
PoCやプロトタイプを迅速に形にできるようになった
変わらなかったこと
- テストは引き続き重要。むしろ
TDDの価値は 上がっている - 開発スタイルとしての 「協働しながら作る」 という姿勢も変わらない。ソロで書ききるのではなく、書き手と確認者が常にやり取りしながら品質を上げていく
- 構図としては「人間が AI とペアプロをしている」のと同じ。レビューと対話の重要性は変わらない
わかったこと
- リソース（エージェントの並列度）を上げても、最終成果物の品質は単純には良くならない
- 理由（推察）: 並列で動くエージェント同士の出力が 衝突・重複 し、統合コストが膨らむ。さらに レビューや意思決定の人間側が律速 となり、生成スピードを上げても ボトルネックは下流に移るだけ。前提となる仕様や設計の解像度が低いまま並列化すると、解釈のばらつきが増えて手戻りが増える、という構造もありそうです
- 内部品質の担保は引き続き必要。
モジュール性/保守性/再利用性/可用性/理解容易性/変更容易性のうち、- 理解容易性は人間と AI で観点が同じ
- 変更容易性は AI にとっても重要な観点 となる
つまり、「AI を入れさえすれば成果が出る」わけではなく、入れる前の基礎力（内部品質・設計力・プロセス）がそのまま結果に乗ってくる ということです。並列度を上げても線形に伸びないのも、内部品質の議論が引き続き必要なのも、すべて「AI は元々の力を増減させる装置だ」という見方で繋がってきます。
その基礎力と AI の関係を一言で表したのが、次の整理でした。
AI は増幅器（Amplifier）である。
ソフトウェア開発が上手な企業ほど価値が増幅され、下手な企業はその弱さも増幅されて淘汰されていく。
これは 企業単位だけでなくエンジニア個人にも同じことが言える はずです。設計力やレビュー力、要件を言語化する力に長けたエンジニアは、AI を従えて成果を何倍にも伸ばせる一方、基礎が弱い人ほどその弱さが出力にそのまま増幅されて表れる。「AI が肩代わりしてくれるから学ばなくていい」のではなく、増幅される側の基礎力を磨くことの価値が、むしろ上がっている と捉えるべきだと感じました。
そして「これから捨てるべきこと」として挙げられたのが、
「人間がコードを書くこと」
という一節。会場の空気がざわつきましたが、Q&A セッションで補足された通り、これは 「人間が書かなくなる」 のではなく 「人間が書くべき場面を選び直す」 という意味合いに近いと感じました。
Q&A セッションでの補足
午後の Q&A セッションでは、t_wada 氏の現場感覚をさらに引き出す質問が並びました。
| 論点 | 要旨 |
|---|---|
| これからの開発スタイル | 人間 2〜3人 × AI エージェント複数を 1 チームに。モブプロ形式 で、議論・意思決定・教育を内包する |
| コードレビュー | 全量は見ない。テスト項目の意図やテスト結果を AI にレビューさせる運用へ |
| 新人教育 | ステップバイステップ型を否定する風潮があるが、それは 間違い。基礎から少しずつ教えることが重要 |
特に新人教育の話は、
「我々（業界）がおかしくなっている」
という強い言葉で語られていたのが印象的でした。AI で時短できるからといって、教育まで時短してよい理由にはなりません。
「AI が増幅器である」ならば、その増幅の対象には技術力だけでなく、ガバナンスの脆弱性も含まれます。規模を拡大すればするほど、リスクも等倍で膨らむ。この危機意識を正面から扱ったのが次のセッションでした。
AIガードレールとしてのAPIガバナンス
Postman の草薙昭彦氏のセッションは、AI エージェント時代の API 管理を 「ガードレール」 というメタファーで整理する内容でした。
中心となるメッセージは、
人間中心の DX から、AI エージェント中心の AX（Agent Experience）へ。
Postman は 「AI-Ready API」 というコンセプトを掲げており、API は単なるデータ授受の経路ではなく、AI に対する制約と契約の媒体 として再設計されるべきだ、という立場でした。
「AI がうまくやってくれるから API 管理は不要」という見方には明確に否定的で、その根拠として OWASP Top 10 for Agentic Applications のようなセキュリティリスクが提示されました。
ガバナンスは 2 種類に分けて整理されます。
| 種別 | タイミング | 主な対象 |
|---|---|---|
| 静的ガバナンス | 構築時 | 設計、テスト |
| 動的ガバナンス | 実行時 | 運用時の監視、検問、停止 |
そして、API そのものが 「知的なフィルター」 へと進化していく、という展望が示されました。
- 動的認可
-
意図の検証 とセマンティックバリデーション（
型のチェックから 「意味のチェック」 へ） - 出力フィルタリング
- キルスイッチ とリソース制御
特に印象的だったのが、
「この操作はビジネスルールに反していないか」を、API 呼び出し直前に AI 自身に検証させる。
というアイデア。AI が AI の意図を検証する構図ですが、トレース可能な層 に検証ロジックを置くことで、責任の所在が明確になります。
加えて、AI から見えるツールやスキルを限定する（露出を絞る）ことが重要、という補足もありました。MCP（Model Context Protocol）のようなプロトコルで 「既存の API を AI が扱いやすい形式に変換する」 アプローチも紹介されており、ここは持ち帰って検証してみたい領域です。
技術の原則とガバナンスの方向性が見えてきたところで、次の問いは「では組織とチームはどう変わるべきか」です。Sansan CTO の視点は、開発プロセスから人材育成まで幅広く、しかし極めて実践的でした。
エンジニアリング組織の変わるべき点・変わらない点
Sansan CTO 笹川裕人氏のセッションは、エンジニアリング組織の論点を 「開発プロセス」「新人採用」「ピープルマネジメント」「キャリアパス」 の 4 軸で整理する内容でした。
開発プロセス
変わること
- 各工程のスピード。テストを作る作業は AI が担うようになる
- ただし、テストの評価（
Assert）の観点は 人間が与えたほうがよい。特に UI 部分は差別化要素になる
変わらないこと
- 「問題を解決する」 というエンジニアリングの本質
新人採用
変わること
- 見るべき観点が 広く、深く なる。関わる範囲が広がり、専門性も深くなる
- ドキュメント執筆能力の重要性が上がっている。他人が読んで理解可能な文章を書く力 があるかをみる。
変わらないこと
- 技術力は依然として必要。コードはブラックボックス化していくが、設計・パフォーマンス・セキュリティ・拡張性・一貫性 を考慮して AI に指示する部分では技術力が要る。
ピープルマネジメント
多くの人は実力の 85% の出力で仕事をしている。
成長志向の強い人は 100%、何かのイベントで追い込みをかけると 125〜130% まで出る。
リーダーの責務は チャレンジを創出すること。組織の課題を広く把握し、様々な分野にある程度詳しく、面の皮を厚くしてどこにでも入っていく。地味ですが、テックリードに本質的に必要な姿勢だと感じました。
キャリアパス
エンジニアのキャリアの今後として、次の 2 軸が示されました。
- 深い専門性を備える方向 — ツールやフレームワーク開発、自社固有課題への技術的アプローチ
- プロダクトマネジメント方向への遷移 — 技術バックグラウンドを持って 「何を作るか」 に踏み込む
この 2 つを混ぜながら歩むのが現実的ではないか、という提言でした。一方、仕事の総量と継続的な学習 は変わらない、という締めくくりもまた印象的でした。
「何を変えるか」が見えたとしても、それをチームに根づかせることこそが最も難しい。組織変革の処方箋を提示した前のセッションに対し、このセッションはその「定着」という現場感覚に焦点を当てていました。
変化の速い時代に、テックリードは何から見直すべきか
レクターの広木大地氏らのセッションでは、テックリードが直面する 「定着の難しさ」 が議論されました。
最初の論点は、
AI 活用がチームに定着しないとき、どこから手を付けるか。
一部の人はうまく使えているのに、チーム全体のやり方や成果には繋がりにくい、という現場あるあるです。
語られた示唆は次のようなものでした。
- 自発的・ボトムアップ的な動き を促さないと、世の中から遅れる。新しい技術を触ることが当たり前になるエンジニアチームになるべき
- エンジニアが望む環境（PC や AI）を用意するのは リーダーの仕事
- ただし、変化を定着させるには トップダウンで強制 することも必要
そして、話しが膨らんで「AI にパワポ資料を作らせるのはナンセンス」という指摘。そもそもパワポであるべきか を問い直し、Excel 方眼紙で設計しているのと同じ構図に陥っていないか、と。次の時代に合わせたフォーマットを考えるべきだ、という挑発的な提案でした。
個人の AI 活用をチームのやり方にする方法としては、
- モブプロを活用 し、AI を使ったコーディングやレビューの知見をチームで学ぶ
- メンバー固有の作り方や進め方をチームに共有して 民主化する
ことが挙げられていました。新しい概念や技術トレンドの本質を見誤らないためには、
「テックリードであれば先端技術を把握しておくべき」
「ツールはたくさん使っていきましょう」
と、シンプルかつ実践的な指針が示されていました。
ライトニングトークから — 印象に残った視点
ライトニングトークも実務に効くトピックが揃っていました。ここでは特に持ち帰り価値が高かったものをピックアップします。
connpass エンジニア「サプライチェーン攻撃を防ぐ方法」
GMO の TAKUMI Guard を活用した事例。ハッシュ検証 + パッケージマネージャの改善 という 2 軸でリスクを低減するアプローチが紹介されました。AI エージェント時代は依存パッケージへの攻撃面が広がるため、この領域の重要性は今後さらに増しそう です。
ダイキン工業「エフェクチュエーション知ってる？」
手持ちの資源から可能なことを考え、偶然を取り込みながら 進めていく。
社内コミュニティを地道に作りながら、目指したい姿（ビジョン）を常に示してアップデートしていく、という運用論が良かったです。AI 活用の社内推進にもそのまま転用できる視点でした。
寺田学氏「TechLead の役割」
Python コミュニティで著名な寺田氏のトーク。テックリードは「技術選定、設計、マネジメント」だけではなく、
「決め方を決める」こと
が役割だ、という整理が印象に残りました。なぜチーム開発が難しいかは、メンバーが様々な価値観を持っているから。だからこそ、
合意形成はスキルではなく「設計」であり文化
だという指摘です。PoC や技術検証の実験を 「何かしらの仕組みで残す」 ことの重要性も語られていました。
逆瀬川氏「Agent 時代に価値を届け続ける組織開発」
「開発は速くなったのに、リリースが安定しない」
「作るのは簡単になったが、ユーザー体験を作るのは難しい」
というオープニングが鋭かったです。hook、pre-commit、CI などのハーネス整備、ドキュメントの 4 分類、人間の役割が 「書く」 から 「選び・判断する」 へシフトしている、といった論点が語られました。
最後の一言、
「速いからこそ、立ち止まれる組織が重要」
は、この日聴いたセッションすべてを貫く 通奏低音 のようでした。
なお、澁井雄介氏（LayerX）の 「LLM 時代の検索アーキテクチャと技術的意思決定」 は、エージェントのための検索における要件の広がりを扱う内容で、別途ゆっくり咀嚼したいテーマでした。
持ち帰った学び
複数のセッションを通じて、登壇者たちが異口同音に語っていたのは、驚くほど一貫したメッセージでした。異なる会社・立場・技術領域から語られながら、すべてが同じ地点に収束している——その核心を自チームへの示唆として以下の5点に凝縮します。
- AI は増幅器。組織の弱さも増幅されるので、土台を整えること のリターンが上がっている
-
変えるべきはフォーマットと習慣。パワポや
Excel方眼紙のような 「次の時代に合わない型」 を見直す勇気が要る - 教育と合意形成は時短してはいけない。中〜長期の投資として向き合う
- テックリードの役割は「決め方を決める」こと。技術選定の前に、合意形成の設計 が要る
- 速いからこそ、立ち止まれる組織を作る
そしてこの日、いちばん刺さった言葉を最後に置いておきます。
❌ これからのエンジニアは AI を 使うべき
⭕ AI を使うと こんなに楽になるよ と伝えるべき
「使うべき」 と命じる側に立つのではなく、「楽になる体験」 を伝えていく側に立つ。テックリードとして自分が立つべき位置を、改めて考えさせられた一日でした。
今回のカンファレンスを通じて感じたのは、先進的な企業はいずれも「AI をどう使うか」という段階をすでに超え、組織体制・チーム運営・人材育成の根幹から問い直す変革フェーズに入っているという事実です。この変化は一時的なトレンドではなく、エンジニアリング組織の競争力を左右する構造的なシフトと捉える必要があります。
私たちも、この波に受け身で対応するのではなく、自らが変革を牽引する側に立つことが求められています。技術の基礎力を磨きながら、チームとしての変革を能動的に推し進めていくことが、今後の差別化につながると確信しています。