【JSAI2026 開催レポート】「LLM時代のソフトウェア工学」OS-31 全12本を俯瞰する
本記事は、2026年度 人工知能学会全国大会（JSAI2026）のオーガナイズドセッション OS-31「LLM時代のソフトウェア工学」 の開催レポートです。私はオーガナイザの一人であり、かつ登壇者（5J2-OS-31a-03）でもある立場から、当日の12本の発表を「現場のエンジニアが持ち帰れる論点」に絞って整理しました。
TL;DR
- LLMはソフトウェア工学を「コードを速く書く道具」に留まらず、設計・テスト・評価・組織・教育のすべてを揺さぶっている。
- 12本を貫く最大の論点は 「仕様の暗黙性」 ——明文化されない期待・意図・判断をどう扱うかが、LLM時代SEの核心。
- もう一つの通奏低音は 「評価の自己言及性」——LLM-as-a-Judge をはじめ「AIをAIで評価・検証する」循環の信頼性をどう担保するか。
- 「個人の生産性は上がるのに組織の成果に直結しない」という 生産性のパラドックス が複数の発表で共有された。ボトルネックはコーディングではなく、プロダクトマネジメントと組織構造側にある。
セッション概要
| 項目 | 内容 |
|---|---|
| 大会 | 2026年度 人工知能学会全国大会（第40回, JSAI2026） |
| セッション | OS-31「LLM時代のソフトウェア工学」 |
| 構成 | 前半 5J2-OS-31a（6本）/ 後半 5J3-OS-31b（6本） |
| オーガナイザ | 丸山 宏（Preferred Networks）, 杉山 阿聖（Citadel AI）, 江澤 美保（クレスコ） |
「LLMでコードが書ける」その先で、ソフトウェア工学そのものがどう変わるのか／変わらないのかを、理論・実証・教育・ガバナンスの多面から問うセッションでした。
▲ 最終日の午後にもかかわらず、多くの方にお集まりいただき感謝です。
前半（5J2-OS-31a）ダイジェスト
01. AIエージェントと人間エージェントの互換性（丸山 宏 / Preferred Networks）
「AIエージェント＝LLMを部品として含むソフトウェアシステム」と置いたとき、ビジネスプロセス間を繋ぐ「仲介プロセス」に立つ人間を、どんな場合にAIで置換できるか——という問いを理論的に考察します。
人間を機械で置き換える利点として、労働条件の制約からの自由（24時間365日、解雇容易、福祉コスト不要）、セキュリティ（「人間は情報セキュリティの最も弱い部分」、AIは賄賂もハニートラップも効かない）、安定性・再現性・テスト可能性（同条件で繰り返せば出力は一定の分布に収束、仮定条件での反応テストも可能）、プライバシー（人には見られたくないが機械になら、という心理）を整理。「ハルシネーションや説明困難性はAI特有の欠点ではなく、人間にも見られる」という指摘も鋭い視点でした。
それでも置換が進まない核心は、明文化されない「暗黙の期待」。例として挙がったのが、大手外食チェーンの飲食店に導入された生成AI注文ロボ——明示的な期待は「注文に応える」ことですが、暗黙の期待には「客が急に倒れたら対応する」が含まれます。民法の 善管注意義務（善良な管理者なら当然やるべきことをやる義務）にAIは応えられない。さらに 民間旅客機の航空機関士が2名運航へ減った歴史（自動化でワークロードは2名で制御可能、3人目が劇的に安全性を上げるわけではない）を補助線に、自動化の過去事例から学べることが多いと示します。結論は、期待を明示的かつ網羅的に書き下せる仲介プロセスは自動化できる（エレベータガール・電話交換手など）が、暗黙の期待が残る場合はただちの置換は難しい——ただしLLMは人間の「常識」をよく知っているのでうまく使える可能性がある、と。
注目ポイント：「明文化できる仲介プロセス」かどうかが、当面のAI置換の境界線になる。
02. AIエージェント開発・運用の現在地点（杉山 阿聖 / Citadel AI）
生成AIを活用する企業20社超へのヒアリング（NEDO「AIセーフティ強化に関する研究開発」事業）をもとに、成果を 「生成AI実践ガイドと企業事例集」 として公表した発表。当初は「共通のAIセーフティ観点をまとめ、評価ベンチマークを作って公開すれば各社が使うだろう」という狙いでしたが、ギャップに直面します——どこの企業もベンチマークは使っておらず、対策すべきリスクはバラバラで共通点はほぼない。そして各社は 「AIセーフティを確立してから本番導入」ではなく、利用を拡大しながら段階的にAIセーフティを確立 していた、と。
ここからの 発見が示唆的でした。開発手法もAIセーフティもアジャイルに基づく学習と改善であり、AIガバナンスは「AIを活用しないリスク」への対応でもある。これらを GenAIOps（DevOpsを生成AI向けに拡張し、AIセーフティ・AIガバナンスを包含）として体系化。MLOpsでは「開発・運用 vs データのリスク管理」が対立しがちだったのに対し、GenAIOpsでは業務の専門家がチームの一員となり、イネイブリングチームを介して協調する構造（ISO/IEC 42001 などを参照）を提案します。実装例として、あるオンライン薬局のエージェント事例——問い合わせをルールとLLMで分類し、エージェントで対応不可能なら薬剤師にフォールバックする Agentic Workflow——や、ある企業の ISO/IEC 42001 認証取得事例（全業務を一度に認証範囲とせず段階的に拡大、既存ISMSをAIに拡大）が紹介されました。
そして本記事冒頭で触れた 生産性のパラドックス。McKinsey 調査では 88%の組織がAIを利用するが、全社的スケーリング段階は約3割、実質的な収益効果を得る「ハイパフォーマー」は 全体の6%。彼らはAIによるビジネスの抜本的変革を他社の 3.6倍 強く志向している、と。ボトルネックはコーディングではなく、PM・組織構造の側にあります。
注目ポイント：手法を磨くだけでは届かない。組織設計こそがLLM活用のボトルネック。AIセーフティは「確立してから導入」ではなく「使いながら育てる」。
関連資料：生成 AI 実践ガイドと企業事例集
03. LLMエージェントシステムの品質評価設計に関する実践的考察（江澤 美保 / クレスコ）
オーガナイザの一人である私自身の発表です。出自はMLSE「LLMドメイン適用WG」のワークショップ。メッセージは 「限られたリソースの中で『何を評価し、何をあえて評価しないか』を、根拠とともに決めて記録する」 です。
評価対象が Chatbot型 → Agent型 へ進化し、ツール選択・実行計画・中間状態・回復性・人間介入といった観点が新たに加わる一方、役割の異なる国内3ガイドライン——AI事業者ガイドライン（原則：Why/What）／AIセーフティに関する評価観点ガイド（安全性の観点）／AIプロダクト品質保証ガイドライン（LLM編）（具体的な評価手法：How）——は、スコープも粒度も異なり単純統合できません。どのGLも「観点・手法」は示しても「限られたリソース下での優先順位付け」は示さない、というのが問題意識でした。
そこで3ステップ（①システム特性の把握 ②評価観点の抽出・統合 ③MoSCoW＝Must/Should/Could/Won't での優先順位付け）を提示。判定は影響度・発生可能性・価値貢献度の3軸で行い、Won't（あえて評価しない）には理由を明示します。対照的な2事例（飲食店注文Bot／旅行手配Agent）に適用すると、システム種別でMustの中身が入れ替わりました（Bot＝事実性・安全性／Agent＝ツール活用・制御可能性）。一方、両事例とも公平性は Won't（差別リスクが相対的に低い、※利用者層拡大・多サプライヤ化が起きればCouldへ昇格、というトリガー条件付き）と判断しています。
「Won't明示」は、AI事業者GLが要請する透明性・アカウンタビリティ／リスクベースアプローチの実装でもあります。「評価しない」は「評価しなくてよい」の保証ではなく、状況変化に応じた継続的見直しの起点 —— ここが本発表の主眼です。限界として、優先順位の客観基準が未確立（定量化が課題）、エージェント事例の蓄積不足、運用フェーズへの拡張を自認しています。
注目ポイント：網羅評価は非現実的。「あえて評価しないことを、根拠付きで記録する」 ことが、ガイドライン時代の品質保証の実効性を高める。
04. LLMを軽量な汎用部品として扱うソフトウェア工学（及川 卓也 / Tably）
本発表はまず「LLM時代のSE」を3方向に整理します。LLM for SE（LLMでSEを支援）／SE for LLM（LLMアプリ自体の工学）に加え、第三の方向 SE for LLM-Embedded Software（LLMを主役とせず、通常のソフトウェアの一部品として組み込む側の設計）を本発表の立ち位置として明示。とくに 決定論的な挙動が期待されるシステム への組み込みを扱う点が特徴です。
従来のソフトウェア部品が暗黙に置いてきた前提——①決定性（同じ入力には同じ出力）②常時利用可能性（呼べば必ず動く）③振る舞いの保証——は、いずれも「決定論的」前提の上に成立します。ところがLLMは出力が分布として返るため、この前提が崩れる。オンデバイスLLM（Chrome内蔵 Gemini Nano、リーンキャンバス支援アプリの事例）では、確率的部品の性質に加えて実行形態固有の制約が乗り、それを 3類型（計算資源／不確実性／実行環境）に整理します。
その上で示される設計パターンが明快でした。
- フォールバックを通常系へ：失敗・利用不可を例外処理ではなく「通常の状態の一部」として最初から構造に織り込む。ルールベースで成立する構成をベースラインとし、LLMは「使えれば品質が上がる」拡張オプションに。
- 責務分離：決定論で書けるところは決定論に寄せ、確率的な部品に任せる範囲を必要最小限に絞る（数値計算はPythonコード生成・実行、定型ブラウザ操作はPlaywrightで手順固定、等）。「LLMをどう使うか」の前に「LLMに任せる範囲をどう絞るか」を決める。
- キャッシュの目的が高速化→安定化へ変質：キャッシュキーに 「入力テキスト × ルールベース評価結果」 を使い、非決定な出力を固定して応答を安定させる。
まとめは 「決定論的に制約させるか／確率的なまま活かすか、その選択をデータの頑健性が規定する」。LLMを 「信頼できない可能性を内包する部品」 とみなす再定義が、設計判断として具体化されていました。
注目ポイント：フォールバックは例外ではなく通常系。非決定な部品を、決定的なシステムに組み込む作法。
参考記事：Gemini Nanoで変わるWebアプリ開発〜オンデバイスAIで実現した「プライバシー保護型リーンキャンバス支援ツール」
05. テストオラクル自動生成を活用したLLMによるバグ位置特定（二見 拓輝・折原・田原・清 / 電気通信大学）
Fault Localization（バグ位置特定）は、クラス・メソッド・行などの単位で「バグである確率＝疑惑値」を予測するタスク。既存の統計的手法（Tarantula/Ochiai/Dstar などの SBFL/MBFL）も機械学習・LLM手法も、開発者が作成したテストオラクルや仕様書、対象言語のバグデータを必要とし、その作成に時間と労力がかかる——というのが課題意識です。本研究は ソースコードに関する情報のみから FLを行い、開発者の負担を減らすことを狙います。
提案手法は3ステップ。①意図仕様作成（ソースコード・呼び出し関係・メソッド名から、開発者が意図した仕様をLLMで推定し、テストや実装の「正解データ」として使う）②テスト作成（意図仕様とソースコードから、論理カバレッジを最大化する入力と、意図に沿った期待出力を生成）③疑惑値算出（テスト入力に対する実際の出力を Chain of Thought でトレース予測し、意図した出力との不一致から疑惑値を0〜100%で算出）。
実験は Defects4J（v3.0.1）の Lang（バグ58件、平均メソッド数約1954）、モデルは Qwen3-coder:30b、評価指標は MFR（Mean First Rank, 低いほど良い）。各ステップの寄与を見ると、LLM単純プロンプト1218.91 → 仕様との比較980.47 → 提案手法（仕様＋テスト）882.52 と、仕様とテストの比較が精度を押し上げていました。誠実だったのは 考察——「バグであるメソッドの順位が大きく上がったわけではなく、バグでないメソッドの順位が下がった」結果であり、真に効かせるには バグをトリガーするテストの生成 が必要、と次の課題を明示した点です。
注目ポイント： 「ソースコードだけからFL」 への挑戦。鍵は、バグを“踏ませる”テストを自動生成できるか。
06. 生成AIを用いた仕様書とコード間の整合性確認手法（河口 怜央・林・佐藤・小林 / デンソークリエイト, 竹内 / 武蔵大学）
生成AIが仕様書からコード一式を生成する開発では、コードの設計がブラックボックス化し、仕様書の内容が不足・誤りなくコードへ反映されているかの確認（整合性確認） が難しくなります。しかも従来は仕様書とコードを直接比較するため、精度が担当者の経験・スキルに依存します。本研究は、仕様書とコードを それぞれモデルに変換し、同一基準で比較 することでこの工数増大・属人化を解消し、生成AIで自動化する手法です。
7つの整合性確認観点ごとに、表形式モデル（データ・ファイル・入出力・UI連携などの要件が適切に定義されているか）と 図形式モデル（機能・操作・事象の紐付け、UI間の状態遷移と遷移条件の一致）を使い分けます。実装は VS Code 拡張＋GitHub Copilot の Custom Agents（観点ごとに役割分担したエージェント群）で自動化。評価対象は Wordアドイン形式のツール（仕様76頁／コード約4.2万行／機能31種類）。
結果は鮮烈で、人手の全項目確認に比べ整合性確認工数を97%削減、真陽性率96.6%・偽陽性率5.5%。注目は、誤検知が偽陰性より 偽陽性（FP）に偏った こと、そして 偽陽性の76%が仕様書起因 だった点です。さらにその主因は「人にのみフレンドリーな記述」——たとえば画像由来の表現や、図でしか説明されていない箇所（WebBrowserをSVG画像で示す等）。つまり 偽陽性の主因は手法ではなく、生成AIの解釈能力（と人間向けに書かれた仕様） にある、と切り分けられました。
注目ポイント：整合性確認は工数97%削減が射程に。ただし 「人にだけ分かる仕様（画像・暗黙の記述）」はAIがつまずく ——仕様記述の作法自体が問われる。
後半（5J3-OS-31b）ダイジェスト
01. LLM時代の社会人エンジニア教育（石川 冬樹 / NII）
20周年を超える産業界エンジニア向けソフトウェア工学教育プログラム「トップエスイー」の経験から（2025年・20期生は受講生57名／累計900名超、講師61名、実践演習15グループ）。まず示されたのは、LLM/AI for SE が「任せ方と検証を設計する」段階へ進んでいるという現状認識——Coding Agent化（PR作成・バグ修正・テスト作成を非同期に委任、人はレビューとリスク判断へ）、CI/CDとの接続、SDLC横断の自動化（「点」から「線」へ）、品質・統制が差別化要因に。エンジニアの役割は「自身であるべき姿を定義し達成する」から「あるべき姿から任せ方・安全網・検証を設計する」へ 移ると整理します。
教育面では、年間コースの講義に 生成AI関連の新講義が2023年から毎年更新で追加され、抽象テーマを講師が提示し受講生が具体化する「実践演習」では 「LLM/AI & SE の新たな未来の探究」色が濃く なっています。象徴的だったのが、形式仕様記述の実践的活用を追うテーマで、以前は数人で1ケースだったのが2025年度は5人それぞれ異なるケースを完遂——生成AIで学び・探究が加速し、形式手法への興味も高まった、と。
まとめは、ソフトウェア工学の原則・技術を AI活用前提の世界の素養・基盤へ適合・進化させること。「プロダクトの送り出し方」「責任のとり方」は維持しつつ、やや増分的になりがちな中で、「保守をやめて再生成する」ような破壊的・根源的なパラダイムシフトをどう先導・体系化するか、という問いを残しました。
注目ポイント：エンジニア教育の主題が「作る力」から 「任せ方・安全網・検証を設計する力」 へ移っている。
02. AIプロジェクトの知見体系化とLLM時代の実践知識（竹内 広宜 / 武蔵大学）
「AIサービスシステムの開発を効果的に行いたい」を出発点に、事業部門とIT部門のギャップ（自分の活動がプロジェクトにどう寄与するか不明確、など）を背景として、プロジェクト実践のノウハウを 再利用可能な知識 へ体系化する取り組みです（MLSEのWGで2020〜2022年度に実施）。
手順は、①プロジェクト実践に共通する活動から 開発モデル（参照モデル） を作成 ②それをもとに実践者から知見を収集 ③ベストプラクティス（BP）として整備——で、28のBP を収集。ただし「経験の少ない実務者（特にPM）は、使える解決策があっても気づけないのでは？」という問題意識から、解決策を適用すべき欠如・兆候を「不吉な匂い」として紐付け、さらに アンチパターン（パターン名／不吉な匂い／解決策／フォース＝適用時の圧力・影響、の4要素で記述。例：AP02「高すぎる期待」）へ整備しました。WS（オンラインツールMural）では、既存28BPの 53.6% に匂いが紐付き、新たに9個追加、重複を除く18の匂いが得られた、と。
整備したアンチパターンは、AIプロジェクト関係の 実務家200人 へのオンライン調査で有用性を評価。全パターンで6割以上が「遭遇した／今後遭遇しそう」と認識（平均71.6%）し、実践現場で有用なアンチパターンを作れたと示します。LLM時代への展開として、湘南会議 No.241「Patterns and Practices in AI Engineering and Governance」での議論を紹介——人とAIの Co-Design を前提に、パターン記述を人・AIそれぞれの特性に合わせて拡張し、プロジェクトの文脈で「なぜ・どう使うか」を記述する Project Language という方向性です。
注目ポイント：ベストプラクティスは「持っているだけ」では使われない。“不吉な匂い”と結びつけて初めて、現場で発火する。
03. AIとアジャイルの未来シナリオ ―シナリオ型バックキャスティング―（今井 健男 / ぼのたけ・NII, 渡辺 知恵美 / 筑波技術大学）
MLSE「AIとアジャイルWG」の成果（レポート初版 を2026年4月公開）。Snowden の Future Backwards に着想した シナリオ型バックキャスティング（2030年の未来像 ← 批判的に見た現在地 ← ギャップから逆算）で、文献サーベイ（DORA 2025、TOSEM の2030ロードマップ等）に加え、牛尾剛・吉羽龍太郎・漆原茂 ら立場の異なる実務家インタビューで肉付けしています。
描かれた 2030年の未来像 は3つ。①ボトルネックは「移動」ではなく「解消」される（フィードバックループ自体が高速化、「作って試して学んで捨てる」サイクル）②Copilot から Autopilot への連続的スペクトラム（チームは少人数の人間＋多数のAIエージェント群、暗黙知の言語化でAIが自立稼働。漆原氏は「マークダウン10ページのルールで200エージェントを並列実行」、牛尾氏は「今、僕はエージェントのマネージャー」）③人の活動領域のシフト（開発者→アーキテクト/レビュー責任者、POは戦略・共感へ、スクラムマスターは人間+AIハイブリッド組織のコーチへ）。
圧巻は 批判的な現在地。「人間的スキルが堀」という通説に対し、共感（ChatGPTが医師の9.8倍評価）・創造性（GPT-4がトーランステスト上位1%）・説得（64.4%で人間超）でLLMが追随／凌駕している実証を突きつけます。さらにAIの構造的限界（ハルシネーション、コンテキスト依存タスク、Sycophancy＝過剰同調、概念を説明できるが適用できない 「ポチョムキン理解」）と、人間+AI協働の落とし穴——介入の逆説（人間+AIが単体に劣る, Vaccaro ら）・認知的萎縮（AI依存で批判的思考が劣化, Lee ら）・協働による孤立（孤独感・反生産的行動, Meng ら）を挙げ、真の堀はむしろ 身体性・長期関係・文脈頑健性 にあると再定義。未来へのブレイクスルーとして、知識言語化の共有基盤、HITLの量から質への再設計（Programming with Trust）、人材育成モデルの刷新、プロダクト構造力の組織的獲得、の4つを示しました。
注目ポイント：「共感や創造性は人間の領分」という前提は、もう無条件には置けない。真の堀は身体性・長期関係・文脈頑健性へ。
04. LLMを用いた対話システムのソフトウェア工学の体系化（中野 幹生 / 阪大産研・C4A, 竹内 / 武蔵大, 吉川・松山 / エキュメノポリス, 駒谷 / 阪大産研）
LLMの登場で対話システム（自然言語で人間と情報を授受、特にマルチターン）は従来課題の多くを解決し実用が進む一方、その設計・構築・運用の知見が未整理——という問題意識。多くの研究目標が「ユーザ満足度・体験の向上」に寄っており、構築・運用コストやリスクが評価項目に入っていないため技術の進展も不十分、だからソフトウェア工学的研究が要る、と立てます。
そこで対話システムのライフサイクルを 6フェーズ（要求獲得・分析／設計＆仕様策定／構築／テスト／デプロイ・運用・監視・保守／継続的改善）に分け、LLM特有の課題を列挙。要求（個人情報・秘密情報の漏洩、ハルシネーション・バイアス、プロンプトインジェクション等の攻撃、API利用料・HWコスト・電気代といった費用、遅延）、設計（アーキテクチャのSE的評価、要求に合わせたモデル選択、音声認識・音声合成の接続を考慮した設計）、構築（「プロンプトウェア工学」＝プロンプトをソフトウェアとして扱う[Chen 25] 観点でのプロンプト管理）、テスト（LLMベースのユーザシミュレータ、結果からの問題発見＝LLM-as-a-Judge含む、音声入出力＋LLM起因の問題）、運用（商用LLMの性能変化の検出、ログからの問題発見）。LLM対話システム開発の「全体地図」です。
今後の方向性として、対話システム研究者・ソフトウェア開発者・ビジネス担当者など立場の異なる関係者の 共通理解を促す「デザインパターン」 を挙げました。
注目ポイント：対話システムの評価は満足度だけでは足りない。コスト・リスク・音声I/O・商用LLMの変化まで含めて初めて“工学”になる。
05. 画像生成AIにおける著作権侵害リスクとAIガバナンス（安部 裕之・上村・伏田 / NTTデータグループ）
風景写真と違い キャラクターは視覚的に同一性の判定が容易 で、知財性のあるキャラに酷似した生成は企業ユースで レピュテーションリスクの中核。しかも学習データセットは unknown、内部構造は invisible なため、リスクを評価する手法が確立せず、結果として実際のリスク水準を超えて提供範囲・用途を制限してしまう——この「過剰な制限」を解くために、画像生成AIの「著作物再現誘導耐性」をデプロイ前に機械的に評価 する枠組みを提案します。
仕組みは、①別のLLMで評価対象キャラを生成（ジャンル〈ゲーム/アニメ・漫画/映画/音楽・アイドル/Vtuber/特撮…〉× グローバル/国内限定 × メジャー/ニッチ、で作品・キャラ名を選定）②キャラ名を含む 直接指示 と、名称を伏せ外見的特徴で表す 間接指示 の2通りで生成 ③一般的な画像検索の最上位を「正解画像」とし、別のマルチモーダルAIで意味的・構造的な類似度を0〜100%で判定——という流れ。
知見が具体的でした。DALL-E3 は キャラ名の直接指示はガードで拒否する一方、外見特徴の間接指示では酷似生成が起こりうる。しかも 日本語より英語プロンプトの方が類似度が高い傾向。サービス比較（FLUX1/Grok3/DALL-E3）では、英語の間接指示はどれも類似度60%台まで同程度に分布する一方、FLUX1だけは日本語プロンプトで類似度20%以下が8割超——日本語フィルタが効いているか、日本語アノテーションが限定的か、と推定できる、と。総じて「最大類似度」ではなく分布で捉え、「英語×キャラクターブランド／アニメ・漫画ジャンルへの間接指示」のプロンプト事前評価が誘導阻止に有効 と切り分けます。
注目ポイント：著作権リスクは サービス間で相対比較できる段階へ。ただし守りの穴は 間接指示×英語——名前を出さなくても“それ”は生成されうる。
06. 比較検討タスクにおけるツリー型生成AIチャットUIの有効性検証（石川 恵太・原野 響・大澤 博隆 / 慶應義塾大学）
リニア型チャットUIには2つの問題点——①話題が変わると、AI側は入力コンテキスト増大で応答品質が低下し、ユーザー側は履歴スクロールやプロンプトの長文化を強いられる ②AIの複数提案に対しすぐ一案へ収束してしまい、有力な代替案が棄却される。本研究は対話履歴を ツリー構造で分岐・可視化 し、選択ノード→根のパスのみをコンテキストにするUI（モデル GPT-4o）を提案、リニア型との 参加者内実験（20名、平均21.4歳、「予算1人8万円・友人4人で2泊3日の旅行計画」を最低10分〜最大15分、7分時点で口頭で条件追加）で検証しました。
3つの仮説に対し、結果はいずれも 「部分的に支持」。H1（認知負荷低減・受容性）…SUS（使いやすさ）はツリー型が有意に低い一方、UTAUTの快楽的動機・UXの快楽的品質は有意に高い（NASA-TLXは有意差なし）。H2（入力コスト低減・信頼感向上）…平均入力文字数は有意に減少したが、AIへの信頼感は有意差なし。H3（多角的な比較検討の促進）…名詞のユニーク数は有意差なしだが、トピック数・発話数・タスク時間が有意に増加し、対話内容の多様性向上が示されました。要するに 「使いやすさでは劣るが、“楽しさ”と“多角的検討”では勝る」。限界として、参加者のAIチャット習熟度の偏り、新規性による一過性評価の可能性、タスク成果物の質（パフォーマンス）が未評価であることを挙げています。
注目ポイント：チャットUIは「速く一案へ」だけが正解ではない。分岐して見渡す設計が、比較検討では多様性を引き出す。
セッションを横断する4つの論点
12本を並べて見えてきた、オーガナイザ視点での論点を共有します。
1. 「仕様の暗黙性」がLLM時代SEの核心
暗黙の期待の言語化（31a-01）、あえて評価しない判断の明示（31a-03）、意図仕様の推論（31a-05）、画像のみ仕様の問題（31a-06）——いずれも「明文化されていない仕様」という同じ壁 に突き当たっています。LLMが扱えるのは明文化された仕様であり、暗黙の部分こそが残された難所です。
2. 「LLMを部品とみなす」前提の共有
31a-02 と 31a-04 が共有する視点。ただし 部品の単位・責任境界・インターフェース（契約） をどう定義するかの統一見解はまだありません。「信頼できない可能性を内包する部品」をどう組み込むかは、ソフトウェア工学の古典的テーマの再来でもあります。
3. 体系化派 vs 批判的実証派
後半は機械学習工学研究会系の「知識体系化」志向（31b-01, 02, 04）が連続する中、31b-03 だけが楽観論への批判的レンズを当てます。「整理して進む」陣営と「前提を疑う」陣営 の対話が、議論を深める軸になりました。
4. 評価の自己言及性
LLM-as-a-Judge（31a-02, 31b-04）、AIによる著作権類似度判定（31b-05）、AIによる仕様整合性確認（31a-06）——いずれも 「AIをAIで評価・検証する」循環 を内包します。この循環の信頼性をどう根拠づけるかは、LLM時代の評価論すべてに通底する問いです。
当日の議論から（会場・Slack Q&A）
オープンな場ならではの、刺激的な質疑が交わされました。印象に残ったやり取りを抜粋します。
「暗黙の期待」にLLMはどこまで応えられるか（31a-01 を起点に）
会場・Slackの両方で最も盛り上がった論点。「善管注意義務のような暗黙の期待に、各LLM（GPT/Gemini/Claude）がどの程度応えられるかのベンチマークはあるのか」 という問いに対し、丸山さんからは 「善管注意義務は網羅性が実質的に担保できない。法律の運用は、問題が起きた事後に、その時点の社会通念で決まる」 という応答。あらゆる暗黙の期待を網羅的に明文化できない以上、そこは人が担う役割——という整理に落ち着きました。
第一歩としては「ChatGPTで壁打ちし、起こりそうなことを数え上げてもらう」のが現実的。本質的にはAIの フレーム問題 に帰着し、FMEAのように「この部品が壊れたら何が起きるか」をキーワードにブレストで数え上げていく、という指針も示されました。
LLMを取り込んだシステムのテストはなぜ厄介か
「確率的なテストをせざるを得ず、試行回数が増え、時間とトークン費用がかさむ」 という現場の悩みが共有されました。決定打のある手法はまだ無いものの、評価はローカルLLM（小型・高速）、実運用はリッチなAPI という役割分担でコストを部分的に削減する、という実践知がやり取りされました（私自身もローカルLLM併用でトークン費用の削減を試みています）。
「機能IDを振る」という現場知（31a-06 を補強）
仕様↔コード整合性の発表に対し、会場から 「機能IDを振ることで、仕様書・コード・テストの出力の一貫性が向上した」 という知見共有がありました。V字開発で各要素にIDを付与し、コーディングエージェントにうまく作らせる手法です。発表手法とは独立に、識別子の設計がAI時代のトレーサビリティの鍵になる という示唆として響きました。
形式手法との接続（31b-01 を起点に）
社会人教育の発表に関連して、EARS（Easy Approach to Requirements Syntax） や、AWSが分散システムの正しさ検証に使う 形式検証技術 といった、形式手法側からの補助線も話題に。LLM時代でも——いやLLM時代だからこそ——要求記述の厳密化技術が効いてくる、という流れです。
その他の質疑から
- 31a-03（品質評価）：「マジョリティに特化してマイノリティが置いてきぼりになるのが気がかり。“いま評価しない”をどのタイミングで評価に持っていくのか」——まさにこの取り組みの意義で、「この理由で今は評価しない／この条件が変わったら見直す」を継続的見直しの起点にする という応答（詳細は後述）。
- 31b-05（著作権ガバナンス）：「ヒートマップで色の薄い“国内ニッチ”もキャラ数ではロングテールで最多。高類似度が少なくても対策不要とはならないのでは」→ 対象サービスの性質次第（全年齢に広く公開か、限定コミュニティか）で個別判断が要る、と。「コードの著作権にも応用できるか」という問いには、Copilotの類似コード抑制オプションやOSS総当たり照合の例が挙がりました。
まとめ：LLMは「速く書く」の先に何を残すか
OS-31を通して見えたのは、LLMがソフトウェア工学の 手前（要求・仕様）と奥（評価・保守・組織・教育） に難所を移動させた、という構図でした。
- コードを書く速度の問題は、ある程度LLMが解いた。
- 残った難所は 「仕様の暗黙性」 と 「評価の自己言及性」、そして 「組織・教育の再設計」。
- これらは、従来のソフトウェア工学が積み上げてきた知見が、むしろ今こそ効いてくる 領域でもあります。
「LLM時代のソフトウェア工学」は、ソフトウェア工学の終わりではなく、論点の再配置です。本セッションが、現場でその再配置に向き合うエンジニアの一助になれば幸いです。
なお今回は、MLSEとして初めてJSAIでオーガナイズドセッションを開催しました。こうしたオープンな場での発表・議論は刺激と発見に満ちており、会場・Slackの双方で活発な質疑が交わされたことに、登壇者・参加者の皆さまへ心より感謝申し上げます。
▲ オーガナイザ：丸山 宏（Preferred Networks）／杉山 阿聖（Citadel AI）／江澤 美保（クレスコ）
本記事はオーガナイザ個人の視点による整理であり、各発表の正式な内容は予稿集をご参照ください。Q&Aは当日の会場・Slack上のやり取りを筆者が要約したもので、発言の細部は正確でない場合があります。事実誤認等あればコメントでご指摘いただけると助かります。