はじめに
どんな文章でも、AIが3行に要約してくれる「ELYZA DIGEST」というシステムがあることを知りました。
おもしろそうなので、自分の論文とQiitaの記事を題材に、「ELYZA DIGEST」で要約をしてもらい、自分で書いた論文やQiitaの記事の概要として利用可能かを評価してみました。
文章を読むためではなく、文書を書くために、自動要約機能が活用できるのではないかと考えています。
ELYZA DIGEST
##ELYZA DIGESTに関する記事
https://gigazine.net/news/20210827-elyza-digest/
#実験結果
論文は、執筆者が判断した合格率 0%（0/5）
Qiitaの記事は、執筆者が判断した合格率 42%（5/12）
論文
| 論文タイトル | リンク | ELYZA DIGESTでの要約 | 執筆者による合格判定結果 |
|---|---|---|---|
| 統合テストにおいて影響範囲に対するテスト漏れを防止する「影響波及パス分析法」の提案 | https://www.juse.jp/sqip/symposium/archive/2017/day1/files/ronbun_C1-1.pdf | 派生開発におけるテスト漏れ防止のポイントを解説している。テスト漏れを防ぐためには膨大な量のテストが必要となる。テストの網羅性を確認するため、テストの網羅性を確認する必要がある。 | × |
| 欠陥混入メカニズムの知識を活用したDRBFMの提案 | https://www.juse.jp/sqip/symposium/archive/2018/day1/files/B2-1_ronbun.pdf | 派生開発における、変更漏れの防止に効果的な手法を紹介している。設計制約の変化から影響を受ける箇所を特定する手法を提案。設計制約の変化から影響を受ける箇所を特定する手法も提案している。 | × |
| 派生開発におけるテスト漏れを防止するDifference Statement Coverage分析法の提案 | https://www.juse.jp/sqip/symposium/archive/2019/day2/files/A3-1_ronbun.pdf | ソフトウェアの派生開発における欠陥の分類とその対策手法を紹介している。テスト設計のレビューでは検出できなかったテスト漏れを検出できるという。テスト設計のレビューでは検出できなかった漏れを検出できることが確認できた。 | × |
| 要求仕様の誤解釈を検出するDomain Word Modelingの提案 | https://www.sea.jp/ss2020/download/SS2020-2.pdf | ソフトウェア開発における要求仕様の誤解釈の要因と対策を紹介している。抽象的に表現された用語を「不足している前提知識」で解釈する。テストケースの漏れを誘発しているという調査結果が示されている。 | × |
| 要求仕様に対する形態素ベースドレビューの提案 | https://www.sea.jp/ss2021/download/22-SS2021.pdf | ソフトウェア開発における問題解決法を紹介している。不具合を誘発した曖昧な文は「修飾語」「同義語」を使用していた。修飾語は「使用可能なモード以外には遷移しない」など。 | × |
Qiitaの記事
リンク集のような記事やコードの写経の記事は、自分でも要約できないので、対象から除きました。
| Qiitaの記事タイトル | リンク | ELYZA DIGESTでの要約 | 執筆者による合格判定結果 |
|---|---|---|---|
| ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果 | https://qiita.com/kazuo_reve/items/c1c1d32baed5d60d55c7 | ソフトウェア開発におけるHAZOP入門を3回開催した。全てのワークショップで全員が経験を得るという最大の目標を達成。全てのワークショップで全員が経験を得るという最大の目標を達成した。 | △ |
| 「規模あたりのテストケース数はもはや意味をなさない」という問いに対する考え | https://qiita.com/kazuo_reve/items/50419ce788703746d14a | 規模あたりのテストケース数というメトリクスについて考えてみた。規模はソースコードの規模であることを前提とする。テスト観点ツリーを作成し、テストケースに不足がないか検証している。 | × |
| 派生開発の課題を解決するための工夫 | https://qiita.com/kazuo_reve/items/847a7b0a7988078c6cce | 派生開発の課題解決のために、取り組みをした。テスト項目構成管理、全テスト、自動化、テスト項目構成管理、全テスト。テスト項目構成管理、全テスト、自動化、テスト項目構成管理など。 | × |
| トラブルシューティング(デバッグ)について実体験から学んだこと | https://qiita.com/kazuo_reve/items/d8fff990b8f2e691ad74 | デバッグするときのコツを紹介している。問題を明らかにしようとするのではなく、メカニズムを明らかにする。検証したこと・検証することは記録することが大事。 | △ |
| 文章の推敲・校正の個人的なノウハウ | https://qiita.com/kazuo_reve/items/b15d99759d75f942b9f0 | MS WORDで文章を書いている際の読み方を紹介している。形態素解析の活用、書き換えの活用、音読の活用、前提の文章の読み方。文章の書き換えをすることで、書き換え元の文章の改善点に気づくことがある。 | × |
| 見積りに関する情報と知見 | https://qiita.com/kazuo_reve/items/4d74723faaad1c2875a0 | ソフトウェアの見積もりのバラツキがどのように推移していくのかを解説している。見積もりのバラツキの幅は、最も大きい見積もりで4倍、最も少ない見積もりで0.25倍。不確実性の減るタイミングは、各フェイズで意思決定が行なわれることにで小さくなる。 | × |
| 形態素解析を活用した推敲の方法 | https://qiita.com/kazuo_reve/items/6b7205ffb4ce6ad230ba | 要求仕様書に適用できる「形態素ベースドレビュー」の提案方法を紹介している。推敲のコツとして要注意語句の一覧を作成することを提案している。用語集を作れば「現在,こういう用語でこの文章を書いている」ということが明確になる。 | × |
| ソフトウェア品質シンポジウムでBest Paper Effective Awardを受賞するコツ？ | https://qiita.com/kazuo_reve/items/b5e740328bebad179414 | ソフトウェア品質シンポジウムでベスト PAPER EFFECTIVE AWARDを受賞した。形態素解析を活用した分析で、AWARDを受賞できる論文を執筆するためのコツを紹介。理解しやすい論文を書けば、AWARD受賞の確率がかなり上がると考えられる。 | 〇 |
| マネージャーの役割を引き継ぐときに、メンバから聞いた”継続して欲しいこと” | https://qiita.com/kazuo_reve/items/68b01e25f1bfc7762fcd | マネージャーに「私が抜けても継続して欲しいことある?」と質問。自分が取り組んだことで、メンバに価値があったこと/価値を感じてないことがよくわかる。継続するアプローチのほうが、プロジェクトの成功確率を上げやすいかもしれない。 | 〇 |
| 自分のコーディングでユーザーに喜びの声いただいたこと | https://qiita.com/kazuo_reve/items/b1a4ee2fc421422c6b9a | 組込みソフトウェア開発者向けのツールの開発で、喜びの声があがった。ユーザー操作の手数を10回くらいから2回に削減した。ボトルネックの関数を特定し、独自に関数を作り、ユーザーに喜ばれた。 | × |
| トム・デマルコ「ゆとりの法則」に関係する経験則 ～マネージャーの圧について～ | https://qiita.com/kazuo_reve/items/50fb4bf485e98b9355ed | マネージャーの圧について、専門家に聞いている。マネージャーは、最高のパフォーマンスを発揮できるようにサポートすることが重要。圧をかけられ育った場合、恐れずに挑戦するという行動が苦手になってしまう。 | 〇 |
| 私達のリスク管理の事例（オニオンモデル風の図&プロセス図&未来予想図の活用） | https://qiita.com/kazuo_reve/items/8664746290f092264d35 | リスク管理の手法を解説している。オニオンモデルを応用して、ステークホルダを配置した図を描く。各ステークホルダの状況の変化や発生した事件を毎週記入する。 | × |
#所感
私の論文やQiitaの記事が読み取りにくかったのか、ほとんどの論文・記事で期待している要約結果は得られなかった。「論文の概要を自動生成する」「Qiitaの記事の概要を自動生成する」という使い方は、まだ難しいかもしれない。
ただし、一部のQiitaの記事については、うまく要約できていた。うまく要約できた記事とうまく要約できなかった記事の差を明らかにすると、論文や記事などの文書をわかりやすくするためのノウハウが得られる可能性がある。
自分の論文・記事がわかりにくいので（稚拙な文章なので）、うまく要約できていない可能性がある。
「ELYZA DIGEST」は、手軽に早く実行できる。ある特定の文書であれば的をいた要約できる。これだけでも、すごいと思う。どのような仕組みなのか興味がある。
優秀な論文の論文本文と論文概要を教師データ？として与えれば、いい感じに論文の概要を自動生成してくれるようなシステムができないだろうか。
と思ったら、たくさんありました。。。ただし、日本語はない？
#Qiita内の参考記事
https://qiita.com/taqro/items/ec32b52e5e5e01c2c27d