編集後記「買っちゃった！」と「文章を引き締める技術」：Deep Insider's Eye 一色＆かわさきの編集後記
かわさきからは「買っちゃった！」というタイトルでNPU搭載のノートPCを手に入れてローカルLLMを動かしてみたことについて、一色からは「文章を引き締める技術」というタイトルで「する」や「行う」などの抽象的な表現を具体的な動詞や表現に置き換える技術について書きました。
＠ITのDeep Insiderフォーラム【AI・データサイエンスの学びをここから】を担当しているDeep Insider編集部の一色とかわさきです。8月の初めに公開した編集後記から約3カ月ぶりですね。
編集者が記す「あとがき」である、この編集後記では、執筆／編集時には書けなかった小話や裏話、感想、ぜひ読者にも知ってほしいという話などを書いています。
買っちゃった！（かわさき）
かわさきしんじ
大学生時代にIT系出版社でアルバイトを始めて、そのまま就職という典型的なコースをたどったダメ人間。退職しても何か他のことをできるでもなくそのままフリーランスの編集者にジョブチェンジ。そしてDeep Insider編集部に拾ってもらう。お酒とおつまみが大好き。通称「食ってみおじさん」。最近はすっかり「ダイエットおじさん」に変貌したのでした。10月頭には何と！ 体重は58kgを割り込んで57kg台に。
この後、京都に遊びに行ったり、友人とバーベキューをしたりで体重は恐らく58kg台に戻っているとは思いますが（遊び過ぎが怖くて体重を量ってないという）、第二次減量期はこれにて終了です。年内は以前と同じ運動量（有酸素運動＋筋トレ）をキープしつつ、食べる量を少しずつ増やしながら、現在の体重とバランスする摂取カロリーを調べていく予定です。
そして、年が明けたら、今度こそうまい具合に筋肉が付くような体重増量期を過ごそうと思っています。
かわさきさんは、普段は静岡でリモートワークなので、この前、久々の会社での会食で会った時、パッと見で一瞬、誰か分からなかったのですが、今はだいぶガリガリなんでしょうね。第三次で今度は筋肉ムキムキになるのを期待しています（笑）。（いっしき）
やー、買ってしまいました。Lenovo IdeaPad Slim 5x Gen 9を。編集後記のネタ用に買ってしまいました。
少し前からNPU搭載のノートPCを手に入れたいなと思っていたので後悔はありません。ただし、2024年秋の時点では、Copilot+ PCってだいたいの機種が10万円台後半から20万円台で売られているじゃないですか。お財布と相談して、そこを何とか「10万円台前半」でと思うと、選択肢はこれしかなかったというのが実際です（可能であれば、メインで使っているMac miniも買い換えたいと画策しているのです）。
でもって、このIdeaPad、安いだけあって、CPUはSnapdragon X EliteではなくSnapdragon X Plusで、その中でも一番下のランクのヤツが搭載されています。となると、せめてメモリくらいは多めにしようと32GBを搭載することに決定。そんな感じのモデルがヨドバシカメラにあったのでポチッてしまいました。
何せ手元に届いたばかりで、やったことといえば回復ドライブを作っただけ。そのため、使用感がどうかまでは言えません。この原稿もコメダ珈琲店で慣れないキーボードとエディタ設定に苦労しながら書いていたのですが、仕事場に戻ってきて、手直しする方が気持ち良く原稿が進むくらいにセットアップできていません（笑）。
BitLockerの回復キーは大丈夫ですか？ 回復キーがなくて二度と使えなくなるトラブルがよくあるみたいなので、私がWindows 11機を買ったときは、慎重にチェックしました。
あー、やっぱりその辺をちゃんとやっておいた方がよさそうですね。ネットだと、痛い目に遭っている人がけっこういる感じがしています。
とはいえ、せっかくNPUを搭載しているんだから、ローカルでLLMを動かしてみようと思って、回復ドライブを作りながら、ネットを検索してみるとLM Studioなるものがあることを知りました。さっそくダウンロード／インストールして、さらに言語モデルもダウンロードして、LM Studioに読み込んでみました。
読み込んだモデルはLM Studioが勧めてきた「Llama-3.2-1B-Instruct-Q8_0-GGUF」。取りあえず、何も考えずにLM StudioのチャットUIで対話をしてみたところが以下の画像です。
コメダ珈琲って……とは思いますが、何はともあれ動いているようです。しかも、タスクバーの右端にあるネットワーク接続アイコンは未接続を表すものになっています。なるほど、確かにローカルで動作しているようですね。こいつは素晴らしい！
と、まあ、ほとんど何もしていないに等しい状態ですが、楽しそうなデバイスを手に入れると心が弾みます。次回の編集後記までにはもうちょっと何かしておきたいと考えています。
せっかくローカルLLMを手元で使えるのなら、「試してみた」系の記事をたまに書いてみてはどうでしょうか？ 後述の自己紹介の通り、私は『Deep Insider編集長のネタ帳』を画策しているので、ぜひ『Pythonかわさきの技術遊び場（仮）』などの不定期連載を始めてみるといいかもしれません。これだけ長年、Python言語に向き合ってきたのだから、いろいろとPython×LLMで面白いことが書けそうな気がします！
予想通り、振られてしまった（笑）。何か考えるとしましょうかね。
文章を引き締める技術（一色）
一色政彦（いっしきまさひこ）
＠ITのDeep Insider編集部の編集長。現在展開中の3連載『やさしいデータ分析』『Pythonデータ処理入門』『機械学習入門』で回が進むにつれ、Deep Insider全体の内容が高度化してきたと感じています。そのため最近は、「もっと気楽に楽しんでもらえる記事も、息抜きとして提供したい」と考えるようになりました。そこで、データ分析やAI、機械学習、Pythonに関する気付きや発見を、個人的なオピニオンとともに紹介する不定期連載『Deep Insider編集長のネタ帳』を始めようかと画策しています。恐らく来年からになると思います。
皆さんは、会社などで日常的に文章を書いていますか？ メールや社内向けの説明資料など、何かしらの文章を書いているのではないかと思います。
書いてます！（当たり前か） でも、キーボードを使った原稿書きなので、紙に何かを書く機会がホントに減りました。そのおかげで、字はヘタクソになるし、書き順は覚えてないし、そもそもどんな字だったかをスッカリ忘れているし。この状況、何となくよろしくないなぁと思っています（かわさき）。
本当に今は、紙に文字を書く機会がないよね。とある記述形式の試験で紙に文章を書こうとしたら、全然、思ったように書けなくて衝撃を受けました。それで『日ペンのボールペン習字講座』という通信講座を受けて、読める程度にはきれいに書く指導してもらったのですが、少しはマシになった気がします。とはいえ書く機会がほとんどないからねぇ...。特に若いときは、できるだけノートに手書きがよいと思います。話が脱線しました。
そういった文章は、たとえ同じ内容であっても、文章の構成や表現の仕方によってカジュアルでお気楽な感じにも、フォーマルで厳（いか）めしい感じにもなると思います。だからこそ、TPO（時と場所と場合）や目的に応じて、ふさわしい文章の構成や表現を選択する必要があると考えています。皆さんは文章を書く時に、「どのような構成や表現にするか」を意識していますか？
その重要性に気付いた時の、私のエピソードを紹介しようと思います。これまで私は、基本的にはIT系の技術解説記事をメインに書いてきましたが、企業とのタイアップ記事（いわゆる広告扱いの記事）を書く機会もありました。私の中では、普段の技術解説記事はふんわりと柔らかくて抽象的な書き方でも問題ない場合もあるけど、企業の顔となるタイアップ記事はできるだけビシッと意味がしっかり分かる文章で良い面をより具体的にアピールすべし、という考え方があります。
もう10年以上前だと思いますが、私が執筆したタイアップ記事の査読と校正を他の人にしてもらう中で、当時の＠IT／Windows Server Insider編集長の小川に「文章に絞まりがない」と赤（＝校正の指摘）を入れられたことがありました。その修正内容に「なるほど」と納得したので、今でもその教訓を文章に生かすようにしています。
なるべく平易な文章にしようとは思いますが、なかなかねぇ。それから、最近は敬体（です・ます調）の原稿を書くことが多いのですが、これって「ます」もしくは「です」で終わる文が連続して、書いていて（読んでいても）イヤになることがたまによくあります（どっちやねん）。
確かに「です・ます」をうまく使い分けてリズムを取ることで、「読みやすさ」は変わると個人的には思っています。チャンスがあれば、これに関する個人的な考えも、今後いつか書くかもしれません。
あと、「平易さ」には「読みやすさ」と「理解しやすさ」という2つの軸があるかなと思うのですが、以下の説明はどちらかというと、「読みやすさ」は減るけど、「理解しやすさ」は増すのではないかなと、私は考えています。
そこで今回は、内容をよりビシッと明確に伝えるための文章スキルである「文書を引き締める“表現”の技術」の一つを伝授しようと思います。特に、企業内外にアピールしたい技術的な内容やビジネス文書では、表現の選び方一つで印象が大きく変わることがあります。例えば「自社の技術を紹介する記事」や「説得力のあるプロジェクト提案書」などを書く場面で、今回の技術が役立てられたらうれしいです。
期待を高めるふうに書いてしまいましたが、以下を読んで、「そんなのは当たり前だ」と思われる方もいるかもしれません。その際はご容赦ください。
「する」「行う」という表現に注意せよ！
「する」「行う」といった動詞は、どこでも使える汎用（はんよう）性があり、ほとんど何も考えずに使えるので、非常に便利ですよね。例えば、以下の各文には「する」「行う」という表現が使われています。
- 「説明的な表現にする」
- 「メールをする」
- 「ミーティングをする」
- 「プレゼンテーションを行う」
- 「アナウンスをする」
- 「トラブルシューティングを行う」
これらは分かりやすくて良い表現だと思いますか？ 確かに一般的なメールやSNSなどでのポストにおいては、このような表現の方が好まれる可能性があります。しかし、特にビジネス文章などで、格調高く、より重厚な意味を文章に含ませたい場合には、必ずしも適切ではない、と私は考えます。このような「する」「行う」という表現には、具体性が失われがちだからです。
「する」「行う」などは、ぼんやりした抽象的な表現ですので、より具体的な表現に置き換えられる余地があります。例えば上記の前半の4つは、以下のように、“より具体性を持つ動詞”に置き換えることが可能です。
- 「説明的な表現にする」→「説明的な表現に書き換える」
- 「メールをする」→「メールを送信する」
- 「ミーティングをする」→「ミーティングを開催する」
- 「プレゼンテーションを行う」→「プレゼンテーションを実施する」
最初の例では、「する」よりも「書き換える」という動詞の方がより具体的な意味を持ちますよね。「する」は、実際に何をするのかがよくイメージできません。一方、「書き換える」は、人が文章を修正している様子を脳内映像として思い浮かべることが可能でしょう。それだけ具体性が増しているということです。
また、例えば後半の2つは、以下のように、“より具体性を持つ説明的な表現”に置き換えることが可能です。
- 「アナウンスをする」 → 「アナウンスを行い、情報を共有する」
- 「トラブルシューティングを行う」→「トラブルシューティングを行い、問題を解決する」
最後の例では、「行う」よりも「行い、問題を解決する」という表現の方が、より具体的な説明になっていますよね。「行う」だけでは、実際にどのような目的が達せられるかがイメージしづらいかもしれません。一方、「行い、問題を解決する」は、問題を解決するという目的が明示されており、より説明的で直感的に理解できる文章になっていると思います。
「トラブルシューティング」という語自体が「問題を解決する」という意味なので、具体性のある文にするのであれば、「トラブルシューティングを行い、○○という問題を××のようにして解決した」のようになるといいかと思いました（小並感＝小学生並の感想）。あ、ちゃんと下で捕捉してありましたね。
ご指摘はさすがです。そのように書くことで、より具体的で理解しやすくなることに同意します。
ただし、「トラブルシューティング」という表現は、「問題の原因を探し取り除くプロセス」に重点があると、私は認識しています。一方で、「問題を解決する」という表現は、「最終的な成果」（類語：ソリューション）に重点があり、トラブルシューティングはその一手段に過ぎないと考えています。ですから、「問題を解決するという目的のために、原因を探し取り除くプロセス」がトラブルシューティングの本来の意味であり、単に「問題を解決する」こととは異なると感じます。そのため、上記の例文の表現もやはり適切だと思いました。
もしくは、より多くの人に理解してもらうために、「トラブルシューティング（＝問題の原因を探し取り除く作業）を行い、問題を解決する」とカッコ書きで意味を補足するのも一案ですよね。
もちろん、ITに詳しい人向けの記事であれば、単に「トラブルシューティングを行う」の方が簡潔で読みやすいでしょう。読者層に合わせた柔軟な対応が大切だと考えます。
もちろん、これらは典型的な例です。「前後の文脈により、具体的な意味が把握できる」などの理由で、意図的に「する」や「行う」という抽象的な表現を採用する場合もあります。例えば「問題を解決する」というのが、前後の文脈で明らかであれば、ここであえて説明的に書く方が冗長になってしまうと思います。ということなので現実的には、“より具体性を持つ動詞”や“より具体性を持つ説明的な表現”に置き換えるかどうかを、その都度、判断すべきです。
「する」や「行う」という表現は、無意識によく使う人が多いかもしれません。私も、気が付いたら使ってしまっていることが多いです。だからこそ、推敲（すいこう）する際には、あいまいな表現になっていないかどうかを細かく注意するようにしています。
私の場合、一度書いた文書を注意しながら読んで、より具体的な表現に書き換える作業を行うと、修正箇所が増えて、推敲に時間がすごくかかるようになってしまうデメリットもあります。より具体的な動詞や表現に置き換えるには、より具体的な意味を考えないといけないからです。
ある事象に対して書き手の理解が不十分だと、すぐには明確な動詞や表現は思い浮かばないはずです。まずは事象を深く考えて理解することが重要です。具体的で明確でない理解は、あいまいなまま読者に伝わるはずなので、読者にとってもぼんやりとあいまいにしか理解できない内容になってしまうと思います。
上記の例は単一の文なので、効果があまり目立たないかもしれません。しかし、これが文章全体に広がり、点が面に変わると、文章全体が格調高く、重厚なものになると考えています。特に技術的な説明やビジネスの目的を伝える際に、ここまで説明してきた表現技術は非常に効果的だと思います。
【応用編】より具体的な動詞や説明的な表現を検討せよ！
最後に応用編として、もう一つだけ同様の表現技術を紹介しておきます。
先ほどは“より具体性を持つ動詞”と“より具体性を持つ説明的な表現”に置き換える技術を紹介しましたが、その動詞や表現には具体性のレベルがあります。以下の例を見てください。
- 「データを処理する」
- 「データを計算する」
- 「データを集計する」
- 「データのB列を全て加算する」
1つ目の「処理する」という動詞は、何らかの処理が行われることは分かるものの、具体的な内容は不明瞭です。汎用的に使えますが、非常に抽象的な表現です。
2つ目の「計算する」は、足し算か掛け算かなどは分からないものの、数値計算を行うという具体性が1つ目よりも増しています。やや抽象的な表現ですね。
3つ目の「集計する」は、データの何らかの列の値を合計することが分かり、数値計算の具体的な内容が2つ目よりも見えてきています。やや具体的な表現です。
4つ目の「B列を全て加算する」は、データのどの列の値を合計するかが完全に理解できます。非常に具体的な表現ですね。
このように“より具体性を持つ動詞”と“より具体性を持つ説明的な表現”には、具体性のレベルに強弱があります。どのレベルの強さで具体性を表すかについても、状況や文脈に応じて判断するとよいでしょう。
例えば、「集計する」という表現は「計算する」よりも具体的で好ましい場合が多いです。しかし、あまりにも具体的な表現ばかりを使うと、読者にとっての読みやすさに負担がかかることもあります。記事中に何度も「集計する」という表現を使用するのではなく、適宜「計算する」などのやや抽象的な表現を混ぜることで、文章全体がより読みやすくなることがあります。
勉強になりました！ いや、ホントに他の人がどんなことを考えて、文章を構成しているかってのはあんまり聞けない話なので、面白かったです。
この仕事をしてきて、自分の経験で学んだことを他人にシェアすることってないですよね。よかったらかわさきさんも、文章で気を付けている自分なりの秘訣（ひけつ）などあれば教えてください！
何かあるかなぁ……。あるはずなので、そんな機会が訪れたらまとめてみることにします。
以上、表現技術の一つを紹介しました。人気があるようなら、またいつか他の文章技術も紹介したいと思います。
余談になりますが、2022年5月に書いた「AIで人を画像認識して走ってくるロボット犬を作ってみよう」という記事では、Mini Pupperという製品を使いました。このMini Pupperが、「Mini Pupper 2G」という新商品名で、ChatGPTなどの生成AIに対応し、1時間以内で組み立てられるほど簡単にリニューアルされました。2024年10月18日まではクラウドファンディングのKickstarterで支援を通じて入手可能でしたが、10月23日時点ですでに支援への参加は終了していました。ちなみに、私は今回は入手を見送りました……。Mini Pupperのバージョン1も今後、マルチモーダル生成AI機能を組み込んで「Mini Pupper 1G」にアップデートできそうなので、興味がある方はぜひチェックしてみてください。
Copyright© Digital Advantage Corp. All Rights Reserved.