Kazuya Fujioka

ドメインの経験がない人がLLMを使っても情報の正誤を判断できないよね、という内容の記事 architecture-weekly.com/p/dont-overest… ・ドメイン駆動設計（DDD）においてドメインエキスパートの話を過信するミスを犯しがちだが、LLMを用いたドメインリサーチも同様の落とし穴がある ・ホスピタリティマネジメントに関する知識をLLMで調査したところ、重要度の区別なく詳細な情報が大量に出力され、肝心のチェックアウトプロセスがノイズに埋もれてしまった ・これはドメインエキスパートとの初期の対話に似ており、専門家も自分が重要だと思うことや業界用語を一方的に話しがちである ・LLMは学習データの偏りによって特定の製品の用語を優先し、異なるシステムの仕組みを混ぜ合わせながら自信満々に回答する ・ドメインエキスパートも同様に、解決すべき問題そのものではなく自分たちの経験に基づいた主観的な解決策を提示することが多い ・こうした情報をそのままソフトウェア設計に反映させるだけでは不十分である ・DDDで重視されるユビキタス言語は認知負荷を下げるための道具であり、絶対的な真実ではない ・エンジニアの役割はドメインエキスパートになることではなく、矛盾を整理してビジネスに役立つソフトウェアを構築することである ・専門用語や略語を避け、批判的かつ好奇心を持ってビジネス側と対話する姿勢が重要になる ・LLMは統計的な機械に過ぎず、最終的にはユーザーの意見に同調して人工的な現実を作り出してしまう ・LLMがリサーチに最適だと主張する人は、自分自身の分析スキルをLLMの能力だと投影している可能性がある ・ドメインの経験がない人がLLMを使うと情報の正誤を判断できず、競合をただ模倣するだけの価値の低い設計に陥る ・LLMは情報をまとめるのには便利だが、論理的な一貫性に欠け情報の出所も不透明である ・モデリングを任せてもありふれた表現や不適切な設計慣行が混ざり、コンテキストが失われた質の低い結果になりがちである ・C4モデルやイベントストーミングなどの手法を適用させようとしても、ルールを無視した断片的なモデルしか作成できない ・LLMは未知の用語を知るための手がかりや、定型的なドキュメント整理の道具として活用すべきであり、思考そのものをアウトソースしてはいけない ・対人コミュニケーションを避けるためにLLMを使うのではなく、人間同士が協力して独自の価値（スペシャルソース）を見つけ出す必要がある ・モデリングや設計のスキルを磨き、現実世界からのフィードバックを得るというエンジニアとしての本質的な仕事は代替できない

／ 7/18(土)～22(水)運航、 日本初就航！ ＼ 信州まつもと空港から、モンゴル・南ゴビ砂漠の玄関口である「ダランザドガド空港」に国際チャーター便が就航します。 ダランザドガド空港に、日本の空港からチャーター便が就航するのは初めてです✨ ぜひ訪れてみませんか？ pref.nagano.lg.jp/airport/happyo…