投稿者 global-ai-media 
電子フロンティア財団（EFF）が発表した、オープンソースプロジェクトへの貢献に関する新方針が、ソフトウェア開発の現場に重要な問いを投げかけています。AIによるコード生成を容認しつつも、ドキュメント作成においては「人間による記述」を必須としたこの決定は、AI活用における「効率化」と「説明責任」の境界線をどこに引くべきか、日本企業にとっても実務的な示唆に富んでいます。
EFFが示した「AI活用の境界線」とは
デジタル権利の保護を目的とする非営利団体、電子フロンティア財団（EFF）は、同団体のオープンソースプロジェクトへの貢献に関するポリシーを更新しました。その核心は、「LLM（大規模言語モデル）によって生成されたコードの提出は受け入れるが、ドキュメントや説明文については人間が書かなければならない」というものです。
この方針は、昨今のGitHub CopilotやChatGPTなどを利用した「AIコーディング」の流れを否定するものではありません。むしろ、コード生成による生産性向上は認めつつも、そのコードが「何を意図しているのか」「どのような仕様なのか」を説明する言葉については、人間が責任を持つべきだという姿勢を明確にしています。
なぜドキュメントは人間でなければならないのか
コードとドキュメントには決定的な違いがあります。コードはコンパイラやインタプリタによって実行され、テストによって動作検証（Verification）が可能です。AIが生成したコードにバグがあれば、テストで弾くことができます。
一方で、ドキュメントは「意図」や「文脈」を伝えるものです。現在の生成AIは、確率的に「それらしい文章」を生成することには長けていますが、背後にある設計思想や、なぜそのような実装にしたのかという文脈を真に理解しているわけではありません。
もしドキュメントまでAIに丸投げしてしまうと、以下のようなリスクが生じます。
- ハルシネーション（もっともらしい嘘）のリスク： 実装されていない機能があたかも存在するように書かれたり、誤ったAPIの仕様が記述されたりする可能性があります。
- 責任の所在の不明確化： 将来的にバグやセキュリティホールが見つかった際、ドキュメントがAI生成のままだと、「なぜその設計にしたのか」という経緯が追えず、保守性が著しく低下します。
日本企業の開発現場における「空洞化」への懸念
日本企業、特にSIerや受託開発、あるいは社内のDX推進プロジェクトにおいて、ドキュメント作成はしばしば「コスト」と見なされがちです。「AIに仕様書を書かせて工数を削減しよう」という動きも見られますが、EFFの方針はここに警鐘を鳴らしています。
確かに、定型的なコードの解説や、既存コードからの要約生成にAIを使うことは有用です。しかし、要件定義書や設計方針書、APIの利用ガイドラインなど、他者が読んで判断を下すための重要文書をAI任せにすることは、プロジェクトの「中身（インテリジェンス）」を空洞化させることと同義です。日本の商習慣として重視される「品質」や「信頼」を担保するためには、AIが出力したものを人間が咀嚼し、自分の言葉として再定義するプロセスが不可欠です。
日本企業のAI活用への示唆
今回のEFFの事例を踏まえ、日本の組織におけるAI活用のガイドラインや実務において考慮すべき点は以下の通りです。
1. 「作成」と「検証」の役割分担を明確にする
コード生成などの「実作業」においてはAIの積極活用を推奨する一方で、その成果物が正しいことを保証するドキュメントや仕様説明においては、必ず人間が主体となるようルール化すべきです。「AIが書いた説明」をそのまま顧客や後工程に渡すことを禁止する規定も検討に値します。
2. 技術伝承と教育の視点を持つ
新入社員や若手エンジニアが、AIにコードを書かせ、AIに説明を書かせるようになると、技術の「中身」を理解する機会が失われます。ドキュメントを自分の言葉で書くことは、技術理解を深める重要なプロセスです。人材育成の観点からも、ドキュメント作成のAI依存には慎重であるべきです。
3. ガバナンスにおける「人間の介入（Human-in-the-loop）」の定義
AIガバナンスを策定する際、「最終的な成果物の説明責任は人間にある」という原則を徹底する必要があります。特に金融や医療、インフラなど高い信頼性が求められる領域では、コードそのものだけでなく、「ドキュメントの筆者が人間であること（意図を持って書かれたものであること）」が品質保証の一部となるでしょう。