はじめに
Qiita Conference 2026 アフターイベント に参加してきました！
招待制でなんと倍率5倍以上だったらしく、正直当たると思っていなかったのでめちゃくちゃ嬉しかったです。参加者は約100名で、年齢層は25〜35歳がコア層。全員AIに興味のあるエンジニアというアグレッシブな空気感で、自分が最年少だったかもしれません！
今年が初開催ということもあってか、みんな本当にフレンドリーで交流しやすかったです！以前参加した技術カンファレンスでは「常連グループ」ができていてなかなか輪に入りにくい雰囲気があったりしましたが、今回はそういう壁が一切なかった。無料で貴重なセッションが聴けて、近い年齢で活躍しているエンジニアとリアルに話せる機会って、自分から動かないとなかなか得られないので、本当に参加して良かったです！
開幕早々「隣の方とご挨拶を」という場が設けられたのも印象的でした。イベントのキーワードが HRT（謙遜・信頼・尊敬） というのも良くて、技術の話だけじゃなく人と人のつながりを大切にするカルチャーが感じられました。Qiitaのライターさんともたくさん話せて、自分ももっと記事を書いていこう！というモチベーションをしっかりもらえました。
この記事では、特に刺さったパネルディスカッションと成瀬さんのセッションを中心にまとめます！
パネルディスカッション：AIをプロダクト価値へどう繋げるか
DeNAとKDDIのエンジニアによるパネルディスカッション。「AIをどう使いこなすか」という実践的な議論が怒涛のように続いて、メモが全然追いつかないほど濃い内容でした！
output ではなく outcome で測る
AIの活用を評価するとき、「何を作ったか（output）」よりも「何が変わったか（outcome）」で測るべきという議論がありました。AIで仕事の量を増やすことが目的じゃなく、本質的な価値にどれだけ近づけたかが問われているという視点は、自分の中でもすごく整理になりました！
人間こそがボトルネック
AIがいくら高速化されても、人間が処理できるコンテキスト量には限界があって、むしろそこがボトルネックになるという話。スティーブ・ジョブズが毎日同じ服を着ていた話（意思決定の消耗を避けるため！）が引き合いに出されて、「AIを使いこなすほど、人間側の集中力の使い方が重要になる」という気づきがありました。これは確かに！って感じでした。
AIっぽいアウトプットは「統制の失敗」
AIでスライドを作成した事例が紹介されました。テンプレートを埋めていくだけだと「AIっぽいスライド」になってしまうけど、それは人間がうまく統制できていないだけ！という言葉が刺さりました。design.md のような形でチューニングの指針を明文化して、スパイラル方式でリアクティブに修正していくことで、人間らしいアウトプットに近づけられるという話でした。
ここで出てきたキーワードが ハーネスエンジニアリング！
AIを暴れ馬に例え、手綱で制御しながら正しい方向へ走らせる設計思想。プロンプトエンジニアリングが「AIに何をさせるか」を設計するなら、ハーネスエンジニアリングは「AIに何をさせないか」「失敗時にどう回復するか」を設計すること。
AIは「できないことをできるようにする」のか？
この問いに対して、登壇者の答えはとてもスパッとしていました。
「できないことができるようになるのではなく、自分のスキルの効率化にすぎない」
AIを使いこなせるかはその人のスキル次第。でも、チームに1人できる人がいればチーム全体が使いこなせるようになる、という視点もあって、なるほど！と思いました。
若手育成の難しさ
ベースがある人はAIで学習をどんどん加速できる。でも経験の浅い新人がAIを使うと、「わかった気になるが実はわかっていない」という無意識のサボりが生まれやすいという話がありました。これはリアルな課題ですよね！
対策として紹介されていたのが 仕様駆動開発 のアプローチ。AIに実装させる前に「仕様」を先に書かせることで、全体を俯瞰する力を鍛えるという方法です。アラを探すには全体を見ないといけないので、結果的に理解が深まるという考え方、すごく納得感がありました！
インプットは「本で体系的に学んで、AIで壁打ちして修正する」サイクルが有効というのも参考になりました。
エンジニアの評価基準はどう変わるか
生産性が上がる中で、評価基準の議論も白熱していました！
- 物量（同じ時間でより多くのタスクを進める）
- 本質的な「価値」にどれだけ貢献できるか
- 今後はエンジニアとPMの評価軸が融合していく可能性も
「底辺が広がって、面積が最大化していく」というイメージの例えがとてもわかりやすくて好きでした！
ブランド・ファンの重要性
最後のテーマは新規ユーザー獲得について。議論の結論は「ファンを獲得することが本質」！
Qiitaの記事でも「この人が書いているから間違いない」という信頼が価値になるように、個人・会社のブランド力がそのままコンピテンシーになっていく時代が来ているのかもしれません。
成瀬さんのセッション：脅威をエンジニアリングの糧にして
資料：https://speakerdeck.com/nrslib/turning-threats-into-engineering-fuel-field-edition?slide=3
AIプロダクト開発における具体的な設計思想の話で、パネルディスカッションとはまた違う角度から刺さるセッションでした！抽象→具体の説明の流れが一貫していてすごく聴きやすかったです。
決定論的ワークフローの設計（TAKT開発）
LLMは「確率的な出力」しかできないため、判断材料として使うにはリスクがある。そこで、次のステップへ適切に遷移させる「決定論的なワークフロー実行基盤（TAKT）」を自作しているとのこと！VSCode上でワークロードをすべて自作しているという話に、素直にすごい…ってなりました。
「AIに触らせたくない部分はライブラリを別で作る」「人間の勘をAIが再現できるような設計にする」など、AI時代のコード設計の考え方として非常に参考になりました。「人間が読むテストとAIが読むテストは分かれていくかもしれない」という示唆も面白かった！
巨大プロンプトは破綻する
LLMプロダクト開発では、すべてを1本の巨大プロンプトに詰め込むと破綻する！観点ごとにポリシーと知識を分けて設計することが重要とのこと。心当たりある人も多いんじゃないでしょうか…。
そのAIプロダクト、そもそも成立するか？
プロンプト設計以前に「そのAIプロダクトがそもそも成立するか」を見極めることが大切という話。LLMに任せると「答えは出るが正当性が担保できない」ケースがある。そういった判断・分類タスクはMLモデルに任せる設計が有効とのことで、これはめちゃくちゃ実践的な知見だと思いました！
LLMとMLモデルの使い分け：LLMはテキスト生成・文脈理解に優れる汎用モデルだが、推論コストが高く出力の正当性を保証しにくい。一方、従来のMLモデルは特定タスクへの特化型で軽量・高速・精度が安定しやすい。プロダクト設計では「判断・分類」をMLモデルに任せ、LLMと役割分担するアプローチが有効。
AIに「壊した事実」を伝える
品質保証の観点から、AIに「破壊を観測させる」というアプローチも紹介されていました。テストで壊れた事実をAIにフィードバックすることで、より安全な修正ができるようになるという考え方です。発想が面白い！
おわりに
初開催とは思えないくらい濃くて熱いイベントでした！無料でこのクオリティのセッションが聴けて、しかも登壇者や参加者と直接話せる機会があるって、本当に貴重だと思います。
全体を通して共通していたのは「AIはあくまで自分のスキルを拡張するもの」という感覚。使いこなすための思考・設計・統制の力こそが、これからのエンジニアに求められるんだなと強く感じた一日でした。来年もあれば絶対参加したいです！
⚠️ この記事は参加メモをもとにした個人の解釈・まとめです。登壇者の発言を正確に引用したものではありません。