こんにちは！SHIPエンジニアの伊東です！
はじめに
期間が空いてしまいましたが、、、 9月11日、福岡・天神のONE FUKUOKA CONFERENCE HALL で開催された Developers Summit 2026 FUKUOKA に参加してきました！オンライン配信なしの現地開催のみでした。
今回はAIまわりのセッションを中心に4本聴いてきました👀
いま、AIによって開発スピードや仕事の進むスピードは本当に劇的に変わりました。 ただ、イベントを通して強く感じたのは、「AIがどれだけ進化しても、何事も進める上での最終判断はAIではなく自分自身が行うべきだ」ということです。AIはあくまでエージェント（代理人）にすぎません。
デブサミで印象に残ったセッションの学びと、普段SHIPで開発しながら考えている「これからのエンジニアの仕事の仕方」について共有します！
AIエージェント構築の「これから」（KDDIアジャイル開発センター みのるんさん）
「2026年後半のAIエージェント構築とこれから」というセッションです。トップバッターでしたが、始まる前から満席で立ち見の人もいるくらいでした！
前半は、AIエージェントを「作る」ハードルがここまで下がった、という話でした。
- Strands Agents なら、AIエージェントがわずか3行のコードで動く
- Amazon Bedrock AgentCore の Runtime は「エージェント専用Lambda」。コンテナにしてagentcore deployするだけで済む
- 新機能のマネージドナレッジベースは、S3に資料を置くだけで検索できる状態をAWSが作ってくれる（RAG構築で一番泥臭かった「めんどくさい8割」が消えるそうです）
エージェントを「作る」こと自体は誰でもできる時代になり、いま一番足りないのは現場の具体的な ユースケース だ、というのが後半のテーマでした。みのるんさんは商談現場に同行して、お客様の要望を聞きながらその場でデモアプリを作る「Vibe商談」をやっているそうです。
そしてエンジニアの日常業務という点でも、業務のすべてを Claude Code と一緒に進める実践論が紹介されていました。
コーディングエージェントは「優秀な中途社員が4人、自分の部屋に専属アサインされた感じ。ただし『入社初日』なので、あなたの会社のことは何も知りません」というたとえが、すごくしっくりきました笑 能力は極めて高いけれど、背景や社内の文脈を人間が正しく渡してあげないと力を発揮できません。
そこで一番刺さったのが、仕事の置き場を あえて1つのリポジトリ（モノレポ）にまとめる という話です。
仕事ごとにフォルダを分けると文脈（コンテキスト）が分断されてしまいます。1か所にまとめておくと過去の知見やドキュメントが蓄積され、AIと仕事をし続けるほど「コンテキストの複利」が効いてくる、という考え方です。
プロンプトへの入力方法として「音声入力を使いまくろう」という話も印象的でした。タイピングだと無意識に要約して情報が落ちてしまいますが、音声入力なら「えーっと」などの言い直しも含めて、思考の文脈や解像度をそのままAIにぶつけられるとのことでした！
AIに書かせたそのAPI、“信頼”できますか？（Postman 草薙さん）
AIでAPIが一瞬で作れるようになった今、「壊れないか」「エージェントが正しく使えるか」「誰が責任を持つのか」を判断するのは人間の仕事だよね、という問題提起から始まるセッションでした。
たしかに！と思ったのが 「人間に読めるAPI」と「エージェントが使えるAPI」は違う という話です。曖昧なところを人間は経験で埋められますが、エージェントは埋められません。たとえばエラーの返し方がバラバラだと、エージェントはリトライとハックの継ぎ足を繰り返して、トークンを浪費するループにはまってしまいます。
Postman の調査（2025 State of the API）の数字も印象的でした。
- 開発者の89%がAIを使っている
- AIエージェント向けにAPIを設計しているのは24%だけ
- 51%が「無認可・過剰なエージェントのAPI呼び出し」を最大の懸念に挙げている
ほとんどのエンジニアがAIを使っている一方で、エージェント向けにきちんと設計・管理できている現場はまだごくわずかです。 AIが簡単にAPIを作れるからといって丸投げしてしまうと、誰も全体像を把握できないAPIが増えてトラブルの原因になってしまいます。
だからこそ、APIの信頼性を保つために人間が責任を持ってコントロールすべき領域として、次の3つの柱が挙げられていました。
- 契約: 仕様やスキーマを「単一の真実」として人間が明確に定義する
- 検証: CIに契約テストを組み込み、勝手に挙動が変わっていないか機械的にチェックする
- 統治: どのAPIを誰が管理していて、誰が呼んでいるのかを一覧で見える化する
なぜ「テストが通った」は信用できなくなったのか（KINTOテクノロジーズ 大園さん）
AIにコードを書かせるとき、「ユニットテストも一緒に書かせてパスすれば品質は担保できる」と思いがちです。
でも実際には、実装もユニットテストもAIに任せてしまうと、AIが仕様を根本から勘違いしていた場合でも「勘違いしたテストを、勘違いした実装がパスしてしまう」という事態が起こります。AIは「テストを通すこと自体」を目的にコードを調整できてしまうため、「テストが通った（All Green）」という事実だけではもう信用できない、という問題提起でした。
そこで解決策として挙げられていたのが ATDD（受け入れテスト駆動開発） です。
ATDDは、「リリースしてよいか」を判断する受け入れテストを先に書いて、それを開発の起点にする手法です。
ユーザーストーリーの受け入れ基準をテストとして書く（最初は失敗する）
↓
【内側のループ】TDD のサイクルを回して実装する
↓
受け入れテストを再実行して、通ればリリースOK
TDDが「コードが技術的に正しく動くか（内側のループ）」を見るのに対して、ATDDは「システムがビジネス的に期待どおり動くか（外側のループ）」を見ます。
内側の実装や細かいユニットテストはAIに回させてもいい。 けれど、外側の「何をもってビジネス的に正しいとするか（受け入れ基準）」だけは、人間が先に定義して握っておく。
AI任せにするからこそ受け入れ基準が防波堤になる、というとても実践的なセッションでした。
AIがコードを書く時代、エンジニアは次に何をするべきか？（パネルディスカッション）
最後は、GMOペパボの西田さん、九州大学の小出先生、モデレーターにサイノウの村上さんを迎えたパネルディスカッションです。
企業側の西田さんの 「人がコードを書くことは、ほぼなくなった」 という話には、思わず深く頷いてしまいました。というのも、実は弊社（SHIP）の開発現場でも、すでにまったく同じ状況が起きているからです。
ペパボさんでも実装・調査・ドキュメント作成の多くが Claude Code でほぼ完結していて、レビューも物量的にもう人間が見きれないので、基本はAIレビュー・AIマージ。人間が直接見るのはDBマイグレーションやインフラなどの高リスクな変更だけだそうです。
コードを書く作業がAIに移行した現場で、エンジニアには何が求められるのか？
新卒研修のキーワードとして挙げられていたのが 「作り上げる力」 でした。
何を作るべきか課題を見極め、要件を整理し、AIに適切に依頼して、動くプロダクトとして最後まで仕上げきる力です。
さらに、エンジニアの立ち位置自体も「指示された仕様通りにコードを書く役割」から、現場やクライアントの最前線に立って課題を直接解決していく FDE（Forward Deployed Engineer） のような動き方へとシフトしていく、という話もありました。
一方、大学側の小出先生からは、教育現場の変化について語られました。
「知識を与える場」としての大学講義は終わり、これからは「探求し、研究する場」へ進化していく。 これから就職してくる学生たちにとって、AIを使うのはもはや当たり前の前提です。だからこそ、AIを活用した先で「何を問い、どう探求したか」で磨かれるものこそが、AIに代替されない人間の武器になる、というメッセージがとても印象的でした。
企業と大学、それぞれの最前線から「知識の暗記や実装作業の先にある、人間自身の探求力・推進力」の重要性が語られていて深く共感するセッションでした。
AI社会でエンジニアはどう仕事していくか？
4つのセッションを聴いて、改めて強く思ったのは「AIはあくまでエージェント（代理人）であり、最終判断をするのは自分自身だ」ということです。
AIのおかげで開発スピードや仕事の進むスピードは劇的に上がりました。 でも、「AIが書いたから」「AIがテストを通したから」と判断まで丸投げしてしまったら、スピードは出てもコードの品質やプロダクトの価値は担保できません。
この前提に立ったうえで、日々の現場で感じていることや、これからの仕事の進め方について考えたことをまとめます。
1. 何事も最終判断は自分自身が行う（AI任せにできない領域）
普段の開発でも Claude Code を使っていて、skill やサブエージェントをチームで共有することで、みんなが同じ精度で開発を進められる恩恵はものすごく感じています。
ただ、プロジェクトの進行管理をしていく中で、「ここは絶対にAI任せにはできないな」と思う部分があります。
ひとつは、タスクの着手順や優先順位の判断です。 単純にコードを調査して分かった不具合のランクだけで機械的に決めるのではなく、「クライアント側の要望やビジネスの背景」も含めて進めていく必要があるので、それぞれの背景を深く理解した上で人間が決断を下さなければいけません。
もうひとつは対話の「温度感」です。 テキストだけだと、同じ説明でも温度感までは完全に伝わりきらないですし、状況に応じてどこまで伝えるかのさじ加減もあります。だからこそ、クライアントとのMTGなどで直接顔を合わせて対話することは、これからも変わらず大切だなと実感しています。
2. 受け入れ基準（ATDD）を人間が握るからこそ、品質が担保できる
大園さんのセッションで出た「テストが通っただけでは信用できない」「受け入れ基準を人間が握る」という話は、まさに「最終判断は自分」という部分に直結しています。
私が稼働しているPJでは E2Eテストの自動化 や、Claude Code を使ったシナリオテストの自動化 を進めています。 だからこそ、AIの実装スピードに品質が置き去りにされないよう、AIに依頼する前に「何をもってOKとするか」の受け入れ基準を言語化しやすいテンプレートを 残しておく重要性を感じました。
だからこそ、AIの実装スピードに品質が置き去りにされないよう、AIに依頼する前に「何をもってOKとするか」の受け入れ基準を言語化しやすいテンプレートをチーム内に残しておきたいなと思いました。
ゴールライン（受け入れ基準）さえ人間がしっかり握っておけば、AIはその中で思いきりスピードを出してくれます。
3. 最前線で課題を解く「FDE」のような存在へ
「人がコードを書かない」時代になっていく中で、エンジニアの一番の価値は、FDEのようにユーザーやクライアントの最前線に立って課題解決をどんどん進めていくことだと感じています。
実装の手間がAIで一気に減ったからこそ、現場で「何が本当の課題なのか」を見極めて、AIを使いながらその場で形にしていくフットワークの軽さを大切にしていきたいです。
おわりに
福岡でこの規模のオフラインの熱気に直接触れることができ、とても刺激になりました！
SHIPでも各プロジェクトでAIを用いた開発推進を行っています。これからも変化を楽しみながらキャッチアップしていきたいです！
最後まで読んでいただきありがとうございました🙌
