Upgrade to Pro — share decks privately, control downloads, hide ads and more …

JavaDoc 再入門

JavaDoc 再入門

JavaDoc 再入門 ―AI時代のドキュメント戦略―
2026年05月30日 JJUG CCC 16:30 Room A+B #JJUG_CCC_A

JavaDocはJavaのソースコードからHTML形式のAPI仕様書を生成するプログラミングツールです。
Javaの最初期から存在していますが、このツールの機能についてあやふやな人は多いかもしれません。
また、Java23では Markdown 形式でのドキュメント記述に対応するなど進化をしています。
本セッションでは前半では Java 25 時点での JavaDoc 機能を一通り紹介します。
後半では現代のAIを用いた開発環境も視野に入れて、チーム開発におけるドキュメント戦略はどのようにあるべきかについて解説していきます。
本セッションに関しては特別な前提知識は必要ありません。

* JavaDoc 再入門
* JavaDoc概要
* JavaDocの歴史
* JavaDocの機能性
* ドキュメント戦略
* 契約プログラミングとJavaDoc
* 誰の為のドキュメントか? - ドキュメントの現世利益化
* 構造化と複雑性の抑制 - 組み合わせ爆発との闘い
* シャノンの情報源符号化定理 - 情報量の削減限界

Avatar for nagise

nagise

May 31, 2026

More Decks by nagise

Other Decks in Programming

Transcript

  1. 1 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL JavaDoc 再入門

    ―AI時代のドキュメント戦略 ― 2026.05.30 JJUG CCC Spring 株式会社クレディセゾン エンタープライズ開発センター なぎせゆうき @nagise
  2. 2 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 自己紹介 富山県出身 富山市在住

     株式会社 クレディセゾン  株式会社 凪瀬アーキテクツ 主なジャンル • Java言語仕様 ◦ https://docs.oracle.com/javase/specs/index.html • 書籍 Effective Java の解説ポッドキャスト Tsundokanai Radio ◦ https://podcasters.spotify.com/pod/show/dokanai/ • Javaのジェネリクス • 日本の旧暦のライブラリ (開発中) • Blog : プログラマーの脳みそ • Burikaigi (富山で1月~2月頭で行われるカンファレンス ) なぎせゆうき X (Twitter) @nagise
  3. 3 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL Burikaigi 2027

    2027-01-08 (金) 〜 09 (土) 富山国際会議場 CfPもよろしくお願いします (現時点では募集期間未定)
  4. 4 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 本セッションの方針 セッションレベル

    BASIC • 特別な前提知識は必要ありません。 Javaの入門レベルを想定しています • 専門用語にはその都度解説を入れますが、不明点があれば挙手してください • 可能な範囲でその場で補足を行います 本セッションの内容はなぎせの個人的見解を多分に含みます
  5. 5 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 今日の内容 第一部

    • JavaDoc 概要 • JavaDoc の歴史 • javadoc コマンド • IDEのサポート • JavaDocの記述方法&出力結果 • MarkdownでJavaDoc (JEP467) 第二部 契約プログラミングとJavaDoc • 契約プログラミング • 組み合わせ爆発 • 誰のためのドキュメントか? • 情報伝達の限界点 • AI時代の未来予測
  6. 8 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL JavaDoc概要 JavaDoc

    はJDK付属のツールで、Javaのソースコード中に /** ~ */ 形式あるい は///形式で記述したコメントを元にHTML形式のドキュメントを生成できる 古典的には /** 〜 */ 形式でHTMLを用いたドキュメント記述 2024年Java23以降 /// 形式でMarkdown でのドキュメント記述も利用可能 併用可能なので慌てて書き換えなくても大丈夫
  7. 9 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 公式ドキュメント javadocコマンドのドキュメント

    コマンドオプションなどの記載がある https://docs.oracle.com/javase/jp/25/docs/specs/man/javadoc.html (日本語) JavaDocガイド 関連ドキュメントへのリンクがあるが、ドキュメントの仕様自体は ↓参照 https://docs.oracle.com/javase/jp/25/javadoc/javadoc-tool.html (日本語) JavaDoc Documentation Comment Specification for the Standard Doclet (JDK 25) JavaDocのDocletの仕様書。JavaDocの仕様についてはJava言語仕様には記載されてお らず、この仕様書の管轄となっている。ドキュメントコメントの形式なども網羅 https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html (英語)
  8. 10 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 用語 •

    JavaDoc : JavaDocの機能を指す際はJとDが大文字の固有名詞で記 述 • javadoc : JDK付属のコマンドとしては小文字のjavadocと記述 • JavaDocタグ : @param や @return などの特殊機能を持つタグのこと ◦ ブロック・タグ : @param など。ブロックを構成する ◦ インライン・タグ : {@inheritDoc}などドキュメント中で使用 開発現場での俗用としてはJavaの標準APIのリファレンスを指してjavadocと 言ったり、ソースのコメント部分を指す用例も見られる
  9. 11 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 用語 •

    Traditional Documentation Comments : 従来の /** ~ */ の HTML形式 • Markdown Documentation Comments : Java23以降 /// Markdown形式 • doclet : /** ~ */ 形式のドキュメントを分析し処理する機能を指す ◦ 標準ドックレット : JDK付属の標準形式 ◦ カスタムドックレット : 独自拡張されたドックレット ▪ Google の doclava とか ▪ Asciidoclet : HTML の代わりに AsciiDoc を使用
  10. 12 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL JavaDocドキュメンテーションの記述例 /**

    * <p>メインのドキュメント。伝統的コメントスタイルは HTML5形式</p> * @param index 引数の説明 * @return 戻り値の説明 * @throws IOException 例外の説明 * @since ver 1.2.3 * @author nagise */ public String sample(int index) throws IOException { …… } 詳細は後ほど詳しくやります
  11. 13 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL JavaDoc の機能の歴史

    1995年 Java 1.0 に付属ツールとして同梱配布 1998年 Java 1.2 ではフレーム分割方式に変更 2017年 Java 9 ではモジュール機能 検索機能が追加、HTML5化 2018年 Java 11 フレーム廃止 2022年 Java 18 JEP 413 コードスニペット機能 2024年 Java 23 JEP 467 Markdown
  12. 14 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL JavaDoc以前の歴史 1967年

    プログラミング言語 Simula67 : 現代のオブジェクト指向に繋がる 1968年 ソフトウェア危機 (software crisis) 1971年 UNIX の manページ 1972年 『On the Criteria To Be Used in Decomposing Systems into Modules』(Parnas, 1972) 他モジュールは内部表現を知らない、隠蔽についての論文 1974年 プログラミング言語 CLU による抽象データ型 1984年 文芸的プログラミング (literate programming) 自然言語にコード断片を埋め込みコンパイル可能なソースコードを生成 1990年前後 C/C++ 向け自動ドキュメント抽出ツール群が登場 1990年代 HTML / ハイパーテキスト文化 1995年 Javaが発表される 当時のPCを思うとWebで ドキュメントというのは先進的 1981年IBM 5150 1990年 Windows 3.0
  13. 15 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 1995年時点のJavaDocの注目ポイント •

    JDKに標準で付属するツール • HTML形式でのドキュメントの生成 • /** ~ */ という専用構文の導入 • @param などJavaDocタグによりドキュメントの記法が標準化 • コンパイラとの協業で非推奨機能を警告するなど • カスタムドックレットによる拡張も可能
  14. 16 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL javadocコマンド OracleにはJDK付属の各コマンドの公式ドキュメントがある

    https://docs.oracle.com/javase/jp/25/docs/specs/man/javadoc.html (日本語版) packagenames ドキュメント化するパッケージの名前をスペースで区切って指定 例: java.lang java.lang.reflect java.awt sourcefiles ドキュメント化するJavaソース・ファイルの名前を空白で区切って指定 例: Class.java Object.java Button.java @files javadocツール・オプション、パッケージ名、およびソース・ファイル名の リストを任意の順序で含むファイルの名前を指定 javadoc [options] [packagenames] [sourcefiles] [@files]
  15. 17 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL javadocコマンドオプション 標準javadocオプション

    対応するjavacオプションと同等 --add-modules -bootclasspath --class-path、-classpathまたは-cp --disable-line-doc-comments --enable-preview -encoding -extdirs --limit-modules --module --module-pathまたは-p --module-source-path --release --sourceまたは-source --source-pathまたは-sourcepath --system --upgrade-module-path このほかに標準ドックレットの標準オプションがある → カスタムドックレットだと異なったものになりうるということ
  16. 18 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 標準ドックレットの標準オプション •

    -bottom html-code : 生成された各ページの下部に配置するテキスト • -charset name : 文字セットの指定。HTMLのmeta要素に影響 • -d directory : 出力先ディレクトリの指定 • -doctitle html-code : 概要ファイルの最上部の近くに配置するタイトルを指定 • -link url : 外部参照クラスの既存の javadoc生成ドキュメントへのリンクを作成 • -linksource : 各ソース・ファイル(行番号付き)のHTMLバージョンを作成し、標準 HTMLドキュメントからソース・ファイルへのリンクを追加 • --main-stylesheet fileまたは-stylesheetfile file : 生成されたドキュメントで使用される CSSスタイルの定義を含む代替スタイルシート・ファイルのパスを指定 • no XXX : 特定の出力を抑制する系 -nosince -notree -noindex などなど • --syntax-highlight : {@snippet}タグおよび<pre><code>要素のコード・フラグメントの 構文強調表示を有効にします などなど
  17. 19 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL IDEのサポート IntelliJ

    IDEA や Eclipse など主要なIDEはjavadocをサポートして いる。 クラス名やメソッド名にカーソルを合わせているとホバー表示され るなど。 近年ではAIがJavaDocコメントを参照して理解してくれる
  18. 20 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL JavaDocの記述方法 https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html

    module の JavaDoc module-info.java に記述する module に /** ~ */ や /// で記述 package の JavaDoc package-info.java に記述する package に /** ~ */ や /// で記述 Type の JavaDoc class, interface, @interface, enum, record 等 型の宣言に /** ~ */ や /// で記述 内部クラスなどでも記述することができる Constructor, Method, Field の JavaDoc それぞれの宣言に記述
  19. 21 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL JavaDocタグ ブロックタグ

    • @param など @ で始まりタグ名が続く • 行の先頭に記述する必要がある • 行の先頭の /** や * や空白文字は無視される • @ をタグとして解釈されてたくない場合は HTMLの &#064; を用いる • Markdown形式の場合は @@ と書いてエスケープすることができる インラインタグ • {@identifier content} 形式 • 基本的に説明文中のどこにでも使うことができる(一部タグで例外あり) • content部分に自由テキストがある場合、 {}を含むテキストは数が揃っている必要が ある • HTMLの場合は &lbrace; や &rbrace; を用いて不揃いな記述も可
  20. 23 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 主要なブロックタグ •

    @param メソッド引数や型変数の記述。渡す値の制約や意味合いなどを記載 • @return 戻り値について記述。 Java16以降では {@return text}で記述できる ◦ これはgetterのような単純なメソッドで用いられる簡易記法 • @throws メソッドからthrowされる例外について記載 • @author 著者を記述。出力には -author を設定する必要がある • @see 関連項目を記述 ◦ モジュール名 / パッケージ名 . クラス名 # メソッド名(引数型, …) • @since どのバージョンから利用可能かを示す • @spec URL title 外部の仕様などをリンクして示す • @version 現在のリリース番号 • @deprecated 非推奨項目を表す。その理由や、代替を示す。
  21. 24 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL @Depracated について

    Java 5 より前の時代、javadocコメントに @depracated タグがあるとjavacの際に非推奨メ ソッドとして利用を警告することができた。 これはjavadocのタグがjavac側に影響するという特別扱いとなっていた。 Java 5 でアノテーション機能が追加されるとこの役目は @Depracatedアノテーションに移 管される。 @Deprecated(since = "1.0", forRemoval = true) • since : String型。どのバージョンから非推奨となったか • forRemoval : boolean型。将来のバージョンで削除される可能性があるか ◦ デフォルト値はfalse
  22. 25 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 主要なインラインタグ •

    {@code text } textをHTMLやJavaDocタグとして解釈せずに表示 • {@literal text } 同上。@codeはコードフォントで、literalは通常フォントで表示 • {@index word 説明} 索引ページに項目を追加 • {@inheritDoc} 親クラスから項目を継承 • {@link reference label } 他のJavaDocのページへのリンク • {@linkplain reference label } linkに同じ。ちょっとフォントが違う • {@literal text } < とか & とかHTMLのエスケープなしに出力できる • {@snippet 属性 :改行 本文 } サンプルコードの断片(スニペット)を記述 • {@value 静的フィールド } ドキュメントに静的フィールドの値を表示
  23. 26 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL {@inheritDoc} 継承関係のあるクラス間でドキュメントの内

    容を引き継いで用いることができる メソッドの主文で利用できる他、 @paramな どのブロックタグで利用することもできる 複数の継承階層がある場合は {@inheritDoc Parent} といったように階層を指定も可能
  24. 27 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL スニペットの記述 Java18

    からコードスニペット機能が追加されました JEP 413: Code Snippets in Java API Documentation {@snippet lang="java" : 〜 } これは旧来の <pre><code class="language-java">{@literal 〜 }</code></pre> でのサンプルコード記述に比べて楽に記載できます。
  25. 28 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL スニペットのハイライト {@snippet

    lang="java" : IO.println(i); // @highlight substring="println" } スニペット中に末尾コメントをつけ @highlight でハイライト指定 • substring 合致するものが強調表示 • regex 正規表現でマッチする対象を指定 • region 併用可。この行から // @end までの行を対象とする • type ハイライトの種類 bold, italic, highlighted (背景マーカー表示みたいなやつ ) --syntax-highlight をやっていると @highlight によるハイライトが効かない
  26. 29 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL Markdown形式でのJavaDoc記載 Java23

    から Markdown形式でのドキュメント記載ができるようになった JEP 467: Markdown Documentation Comments /** 〜 */ に代わり、 /// コメントを使用。見た目が C#っぽくなった 従来のコメントはHTML形式だったためHTMLのタグを記述する必要があった また、型変数 <T> や不等号、アロー演算子や &といったHTMLでエスケープが 必要が文字が含まれているとそのままでは表示できなかった → HTMLの文字参照 &#60; や実体参照 &lt; ないし {@literal} を使う Markdown形式ではこのHTML式のエスケープは不要になった
  27. 31 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 本セッション第二部のテーマ 情報理論的制約

    シャノンの定理に基づく通信と圧縮 の限界 • 情報量とは • 情報源符号化定理 • 情報圧縮の理論的限界 構造的複雑性 計算資源を凌駕する指数関数的な 増加 • 契約プログラミング • 組み合わせ爆発 • 探索空間の巨大化 知識の相互作用 ノード間の意味伝達とボトルネック • 意味情報の分散メッ シュ • コンテキストの共有 • ボトルネック AIの実用化による予測困難な時代において、原理的に困難な課題とその論拠を提示します。
  28. 32 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 契約プログラミング バートランド・メイヤーによって提案(英

    : Design by Contract; DbC) 元来は表明(Assertion)を意識したものだが現代 JavaだともっぱらJUnitか • 事前条件(precondition) ◦ 呼び出し側が守る条件 ◦ 引数に何を渡すのか、オブジェクトの状態がどうあるべきか等々 ◦ フィールドを参照するならそのフィールドも ◦ プロパティファイルの読み込みや DBの値の読み込みなども • 事後条件(postcondition) ◦ 呼び出された側が保証する条件 ◦ returnされる値が何であるか、どういう時に例外が出るか、副作用は何か ◦ フィールドを変更するならそのフィールドも ◦ DBのような外部の状態を変更するようなもの
  29. 33 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 契約プログラミング メソッドを呼び出す際に、呼び出し側が守る

    責務、メソッド側の実装が守るべき責務を 明確にする。 バグが生じた場合など、どちら側で直すべ きか?といった指針にもなる。 古典的にはassertで条件が守られているか を確認する技法が用いられた 現代JavaではJUnitが主流 JavaDocはこれらの条件をドキュメント化す るのに都合が良い メソッド 呼び出し元 事前条件を守る 事後条件を守る 隠れて副作用を及ぼさない
  30. 34 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 契約プログラミング •

    不変条件(invariant) ◦ オブジェクトが常に満たすべき条件 ▪ → これが破れてるとオブジェクトが壊れている ◦ 例えば銀行口座オブジェクトにおいて口座残高は常に 0より大きいとか ◦ 明示されていると文脈理解でより助かる 不変条件(invariant)だけでは不十分なのでフレーム条件( Frame Condition)といったより踏み込ん だ契約を取り扱うこともある 例えJavaプログラム用の仕様記述言語の Java Modeling Language ( JML ) では以下のようなもの がある • 副作用のない純粋メソッド( pure) • 変更可能なフィールド(assignable) • クラスの不変プロパティ(invariant) • ループの不変条件(loop_invariant) • e.t.c. • そしてこれらの論理積、論理和、論理否定などでの組み合わせ
  31. 35 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 契約プログラミングとコードリーディング メソッドを呼び出す際に、その契約が明確

    ならば、いちいち内部実装を見る必要がな い メソッドをひとつの処理の塊として捉えれば よく、このような形でよく構造化されていると 脳のメモリ消費が少ない バグ調査などでは必要に応じて立ち入る 例えばGoogle マップをズームしたりズーム アウトしたりしながら見るような感じ メソッド 呼び出し元 実装を信頼、委任 内部実装を見ない 自分の管轄 コードを見る
  32. 36 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 契約プログラミングと組合せ爆発 文脈的に存在する多数のデータのうち、

    ここに渡せるデータを契約の明示により絞 る効果 • 状態遷移を絞れる • 分岐を絞れる • エラー処理を絞れる • テストケースを絞れる • 未定義動作を絞れる 余計な選択肢に惑わされることを防ぐ 状態空間の削減 メソッド 呼び出し元 使うデータを限定 渡す際の条件も明示 渡すべきではないが型的に 渡しえるデータ群
  33. 37 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 組み合せ爆発 組み合わせを網羅するようなことをしようとすると、指数

    関数的に増えていく これはコンピュータでも太陽の寿命までかかっても終わら ないとかになるので、いかな AIでも組み合わせ爆発を正 面から力でねじ伏せることはできない 1968年 ソフトウェア危機 (software crisis) プログラミングの設計論は組み合わせ爆発への対抗の 歴史でもある。AIの時代でもやはり組み合わせ爆発を 抑えるアプローチが続く と予想される 組み合わせ爆発おねえさんことフ カシギおねえさん https://youtu.be/Q4gTV4r0zRs
  34. 38 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 構造化と複雑性の抑制 契約プログラミングはモジュール化と表裏一体

    コードを細分化したパーツにし、パーツ単位で責務を明らかにし、内部を隠蔽 同じ契約をこなすなら、内部が異なっていても構わない → リファクタリングの容認 組み合わせ爆発の抑制 • 状態を持つものは契約が複雑化する。極力状態を抑える • パラメータが多くなり過ぎないようにする • 生のデータの組み合わせを羅列せず、あり得る組み合わせを保証する型を用意 • ドキュメントで背景情報を説明することも抑制に働く
  35. 39 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL AIなら複雑でもなんとかしてくれる? Q.

    AIなら人間が手に負えない複雑なコードとかもなんとかしてく れるようになるよね? A. AIも組み合わせ爆発を正面突破は無理 なので、人間が今ま でやってきたような複雑さを軽減するようなアプローチをとるので はないか。 既に爆発したものを対応するにはAIも現実的なトークン数では無 理かもしれない。
  36. 40 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 誰のためのドキュメントか? いわゆるSIerの現場では色々なドキュメントが作られるが、そのドキュメントが誰のために

    何のために作られているかは様々 → 開発向け、保守向け、ユーザー向け、契約向け e.t.c. JavaDocは現場のプログラマのためのドキュメントの性質が強い メソッドやフィールドの目的・業務背景・機能性・契約などが書かれ、それらを束ねたクラス の役割が書かれ、それらを束ねたパッケージの役割が書かれ、モジュールの役割が書か れてきた これらは旧来、主にプログラマ間や過去・現在・未来といった時間的隔たりの間での情報交 換に使われてきた 現代ではこれらがAIとの情報交換に使われるようになってきている
  37. 41 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL ドキュメントの現世利益化 開発ドキュメントは、開発フェーズのメンバーにとっ

    ては「現世利益」とはなりにくかった 自分が困らないので手を抜きがち 保守フェーズや更改プロジェクトで質の悪さが発覚 しても、後の祭り AIの登場によってドキュメントは今目の前の開発の 利益として返ってくるようになった メンバーのモチベーションコントロールとして、現世 利益をアピールしていくと良い 5年後? 10年後? 今の利益に!
  38. 43 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 情報伝達の限界点 シャノンの情報源符号化定理

    データ圧縮の可能な限界と情報量についての定理 超大雑把に言えば、情報の可逆圧縮の圧縮限界を示した 直感的には同じワードが繰り返し出てくる文は圧縮しやすい感じ "Fish fish fish fish fish fish fish." "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo." "ちゃうちゃうちゃうんちゃう ?" "しましまにしまっしま "
  39. 44 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 情報量 情報理論的な意味での「情報量」あるいはエントロピー(

    entropy)と呼ばれる概念 あるできごとが起きた際、それがどれほど起こりにくいかを表す尺度 ありふれた出来事は情報量(エントロピー)が低い 稀にしか起こらない出来事は情報量(エントロピー)が高い 熱力学では「乱雑さ」と表現されることが多いが 情報論では「予測しにくさ」「圧縮しにくさ」と捉える方が掴みやすいか? 非常に大雑把な話をすると、よくある出来事を伝えるのは端的な表現で済む AIも低エントロピー領域が得意 同じ知識を共有していると端的な表現で情報を効率よく伝えることが出来る
  40. 45 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL AIがやってくれるから ……

    Q. 現代ではAIが代わりにやってくれるのだから、勉強しなくても 良いのでは? A. 勉強して知識を蓄えておかないとAIに指示出しすることすら困 難。人とAIの間の情報交換がボトルネックに。 わからないことを都度AIに聞いたとしてもAIの説明を理解できる 基礎知識がなければその場で理解できるまで延々と勉強し続け る必要がある
  41. 46 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 意味情報の分散メッシュモデル コード

    仕様 レビュー レビュー 開発 開発 人やコード、仕様などのドキュ メントやAIなど、情報を持つも の同士が情報を交換する必要 がある。 ここで、情報交換に際しては 「同じ知識を共有している」と 効率よく行える 。 素人でもAIで開発が出来ると 喧伝されることもあるが AIと人 との間の情報交換がボトルネッ クになる
  42. 47 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL AIならなんでもお見通しだよね? Q.

    AIがどんどん賢くなったら一言呟いただけでも完璧に対応し てくれるようになるよね? A. 本質的に情報量が足りていない場合は「世間でよくあるケー ス」などで補うことになるため、あなたの思った通りにはならない 可能性が高い。 思った通りして欲しければ、相応の情報量の提供が必要 。
  43. 48 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL ドメイン固有の情報量・異常系の情報量 世間一般で「よくあること」は

    AIに対しても端的な指示で対処可能 世の中に流布していない「うちの会社の特定の業務で扱うシステム」は AIに作業させるにし てもたくさんの情報量を伝えなくてはならない システムの異常系は発生することが少ないからこそ、その対応は情報量が多くなる → 古来より異常系の方がコード量・テスト量が多くなる経験則 AIに端的な指示(少ない情報量)でアプリが作らせると、こうした情報量の多い部分が思っ たようにはならない。前例踏襲のような場合はどうにかして情報を与える必要がある → 既存システムがある場合はそれらのコードなどを知識として渡す必要性
  44. 49 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL AI時代の未来予測 •

    組み合わせ爆発はAIも正面突破できない ◦ AIも爆発を抑えるアプローチをとるだろう • 保守をせずともスクリプトから毎度生成しなおせば良いのでは論には懐疑的 ◦ 挙動を現行踏襲とするには相応の情報量を与える必要がある ▪ ディティールが欠損する可能性 ▪ →これは現行コードなどを与えれば突破できる可能性 • ソースコードなしに直接バイナリを吐くのでは論には懐疑的 ◦ ソースコードは人間とのコミュニケーションツールでもある ◦ 複雑さを抑えるためにも階層的なアプローチを取るのではないか • ドキュメントなくてもAIが補ってくれるのでは論には懐疑的 ◦ 無から情報は生まれないので、ドメイン固有の事情などは補えない ◦ 例外的なことほど情報量が多い。このあたりがカットされがちでは ◦ AIに情報量を与える・エントロピーを下げるドキュメントには意義 ◦ AIによって要約してドキュメントを作るアプローチは実現
  45. 50 © 2024 CREDIT SAISON CO., LTD. CONFIDENTIAL 昨今の話題 •

    AIの生成したコードを読む必要があるか? ◦ コードとスクリプトの情報量の差は何か?そこに関心があるか? ◦ AI と NI いずれも信頼に足るコードが書ける前提が必要 ◦ コードの信頼性をテストのような振る舞いだけで計測できるか? ◦ 保守性という計測困難な指標の存在 ▪ この計測困難な指標に重きをおく必然性があるか? ▪ 大規模になると組み合わせ爆発に対する備えが重要になる ▪ 小規模だと破棄して再生成というアプローチが現実味も ◦ コードがもつ何らかの「情報量」を意識しているなら、それを明確に