先日参加した 『AI Engineering Summit』の各セッションを拝聴したため、レポートにまとめます。
複数のセッションを通じて、AIを活用した開発・業務改善の最前線に触れることができました。
「AIをどう使いこなすか」だけでなく、「AIの出力をどう検証し説明責任を果たすか」「組織としてAI活用をどう定着させるか」「自律型AIエージェントをどう安全に管理するか」という幅広い観点から多くの示唆をいただきました。以下にセッション全体の概要と、特に印象に残ったセッションの詳細、および今後の業務への活用方針をまとめます。
イベント全体の概要
今回のイベントでは、以下のテーマが取り上げられていました。
① AI活用による開発品質の向上
AIの出力品質を、80点から90点以上に引き上げるための具体的な手法が紹介されました。
特に、特性の異なる複数のAIを組み合わせて相互に検証させる「批判的思考の連鎖」や、意思決定のプロセスを可視化・記録する手法など、品質と透明性を両立させるアプローチが印象的でした。
② 組織全体でのAI変革
AIを個人の推奨レベルから、組織の標準へと引き上げた企業事例が紹介されました。
AI活用スキルを評価軸に正式採用すること、現場の「だるさ（業務上の不便）」をAI実装の起点とする文化の醸成、エンジニアが自律的にツール改善を行える裁量の付与など、組織全体でAIを定着させるためには技術だけでなく評価制度や文化の仕組みも重要であると感じました。
また、MCPからCLIへの移行によってAIの作業空間を最適化し、PR自動レビューにより初回レビューまで6分以内を実現した事例は、自動化の効果を数字で示す上でも参考になりました。
③ AIエージェント時代のデータガバナンス
自律型AIエージェントの普及に伴い、データガバナンスの考え方そのものが変わりつつあるという内容でした。
AIエージェントは「悪意はないが自制もしない」存在であり、アクセス可能なリソースや権限を限界まで使い切ろうとする性質があります。そのため、従来の「データを守る」静的な管理から、「エージェントのアクションをリアルタイムで認可する」動的な統制へとシフトする必要があるとのことでした。
人間とAIのIDを分離し、タスク単位で最小限の権限を付与するという考え方は、今後自分たちがAIを使った業務自動化を進める上でも意識しておくべき視点だと感じました。
印象に残ったセッション：「批判的思考の連鎖」と品質保証の仕組み
AI活用が進む中で新たに生まれている構造的な課題が共有されました。
AIの登場により、従来なら数ヶ月かかっていた大規模な開発作業が1日で完成するケースが出てきています。しかしその一方で、完成した成果物だけを見ても「なぜこの設計になったのか」「どういう選択肢が検討されて、何が却下されたのか」がわからない、という情報の非対称性が生じているとのことでした。
また、「上司が部下に指示を出し、部下がAIに指示を出す」という構造は「リモートコントロールのリモートコントロール」状態であり、意図がどこで歪んだかを追跡しにくくなるという問題も提起されていました。AIが生成した成果物が「動いているように見えるだけ」で、仕様の誤解やエッジケースの見落としが潜んでいるリスクは、日々のAI活用においても常に存在しています。
こうした課題を背景に、AIの出力を「ブラックボックス」にせず、品質と透明性を担保するための3つの手法が紹介されました。
① 批判的思考の連鎖（Codex Consultation）
特性の異なる2つのAIをぶつけ合うことで、人間では見落としがちな盲点を自動的に検出する手法です。
具体的には、「問題解決が得意なAI（Claude）」に対して「前提から疑ってかかるAI（Codex）」を組み合わせ、人間は「相談して」と指示するだけでAI同士に議論させます。
Codexは指示や前提そのものを疑う性質を持っており、「PNGのみ対応でよい」という前提に対して「なぜGIFは対応しないのか」と突っ込むような、指示されていない境界条件まで能動的に検証してくれるとのことでした。最終的には、議論の結果が整理されたレポートとして出力されます。
この手法の重要なポイントは、「人間がAIとAIの連絡係（コピペ係）にならなくてよい」という点です。複数のAIを連携させようとすると、人間が間に入って情報を中継する役割になってしまい、かえって人間側の負担が増すという課題がありました。AI同士を直接つなぐことで、人間はより高次の判断に集中できるようになります。
② 意思決定の可視化（Conversation Context Export）
AIとの対話の中で生まれた「検討の軌跡」や「あえて採用しなかった選択肢とその理由」を抽出・記録する手法です。
AIを使うと、完成物だけが残り「なぜそうなったのか」のプロセスが見えなくなりがちです。特に長いセッションの中では、途中で検討し却下した案が記録から消えてしまうこともあります。この手法では、「何をしたか」だけでなく「何をしなかったか・その理由」を明文化しておくことで、レビューする側の疑問を先回りして解消できます。
たとえば、セキュリティ上の理由である構成を却下した場合、その背景を記録しておかなければ、後から別の担当者が同じ構成を再提案するといった無駄が発生します。意思決定のプロセスを残しておくことは、チームのナレッジ継承にも大きく貢献します。
③ プロセスの整合性確認（Sanity Review）
成果物の内容だけでなく、開発・作業プロセス自体の「正気（サニティ）」を確認する手法です。具体的には、「説明したこととやったことにズレがないか」を照合する最終チェックとして機能します。
講演では、AIに作業を依頼する際に「今回は〇〇には対応しません」「〇〇の動作は変更していません」とあえて宣言（断定）してから渡すテクニックも紹介されていました。こうして宣言した内容とAIの出力とのズレを検知させることで、仕様の誤解や漏れを効率的に発見できるとのことでした。また、この「宣言する」習慣は、人間同士のコミュニケーションにおいても、認識のズレを未然に防ぐ効果があります。
学び（反面教師としての気づき）
セッション全体を通じて最も大きな気づきは、「AIを使いこなすこと」と「AIに振り回されること」は紙一重であるという点でした。
今回のセッションを聞く前の自分は、「AIを活用するには、人間が細かく指示を出して間を取り持たなければならない」と思い込んでいました。それ自体は間違いではないのですが、その延長線上に「人間がAIの連絡係になって消耗する」という落とし穴があることは意識できていませんでした。
AIに「思考・議論」の部分まで委ねる設計こそが、より高い品質と効率を同時に実現するという発想は、自分の中の思い込みを大きく覆すものでした。
また、「やったことだけでなく、やらなかったことも説明する」という姿勢についても、改めてその重要性を認識しました。AIを使う・使わないに関わらず、作業の背景や判断の根拠を丁寧に伝えることは、受け取る側との信頼関係を築く上で欠かせないコミュニケーションの原則です。
自分が日々担当している業務の中でも、「完成物だけ渡して終わり」になってしまっていた場面が振り返ると少なくなかったと感じており、この点は意識的に改善していきたいと思いました。
さらに、AIエージェントを安全に活用するためのガバナンスの視点も、今回新たに得た重要な気づきです。自分たちが担当している業務自動化プロジェクトも、将来的には自律的に動くエージェントを扱う場面が増えていきます。その際、特性である「AIは悪意はないが自制もしない」を理解した上で、何をどこまでAIに任せるかの範囲設計や、アクションのログ・承認フローを最初から組み込む意識を持っておくことが大切だと感じました。
---
明日からの業務への取り入れ方（Next Action）
今回の学びを、以下の3点で日々の業務に取り入れます。
① 提出前に「批判的な視点を持つAI」にダメ出しをもらう
コードや資料を作成したとき、先輩やチームメンバーへのレビュー依頼の前に、まずAIに「この成果物の前提を疑って、厳しく抜け漏れを指摘して」と依頼するステップを挟みます。
自分では気づけない論理の穴や、見落としがちな境界条件を事前に洗い出すことで、提出物の質を一段階引き上げてから渡せるようにします。「批判的思考の連鎖」のミニ版を自分の作業フローの中に組み込む習慣として定着させたいと考えています。
② 「やらなかったこと・その理由」を成果物に添える
AIを使って資料や設計書を作成した際、完成物だけを渡すのではなく、「今回はこの選択肢を採用しなかった理由」「この方針で進めた背景」を簡単なメモとして添えるようにします。
受け取る側が背景を理解しやすくなることで、「なぜこうなっているの？」という確認のやりとりを減らし、レビューの質と速度を上げることに繋げます。AIとの対話の中で生まれた意思決定のプロセスを残しておく習慣は、自分のナレッジ蓄積としても役立つと考えています。
③ 報告・レビュー依頼時に「やらないこと」を宣言する
タスクの完了報告や作業依頼をする際に、「今回は〇〇には対応していません」「〇〇の仕様は変更していません」とあえて明示するようにします。
何をして何をしていないかを宣言しておくことで、受け取る側が「言ったこととやったことのズレ」を確認しやすくなり、手戻りを未然に防ぐことができます。Sanity Reviewの考え方を、日常のコミュニケーションレベルで実践していきます。
---
今回のセッションで学んだことは、AIを「ただ使うツール」から「品質を担保するための仕組みの一部」として設計するという視点の転換でした。この考え方を業務に積極的に取り入れ、アウトプットの質と信頼性の向上に努めてまいります。
