浅野直樹の学習日記

Webサイト制作の個人史やWebサイト制作の個人史２で書きましたように、私はAutomate the Boring Stuff with Pythonを読んで感動し、自分の仕事に生かしてきました。

2025年の中頃に第3版が著者ページAutomate the Boring Stuff with Pythonで公開されたので、日本の読者に広めるために、また自分の参照用として、この本を本腰を入れて訳そうと決意しました。

• 日本語訳のGitHub
• Pythonで退屈な作業を自動化する – Pythonで退屈な作業を自動化する（日本語訳の公開ページ）

なるべく早く完成させたいと思っております。

ChatGPTに代表されるLLMが数年前から急速に普及し、もはや生活の一部になったと言っても過言ではないでしょう。

私はITエンジニアやプログラミングスクール講師としてLLMに触れる機会が多いです。

情報がまとまった書籍もいくつか出版されてきたのでそれらを読み、自分なりのLLMとの付き合い方が見えてきたので、ここにまとめます。

１．LLMをどう捉えるか

（１）教科書的な説明

AIに関しては楽観論から悲観論まで幅広い意見が分布していますが、LLMの実像を正確に捉えることが何よりも重要です。

LLMは、コンテンツを生み出すAIである生成AIのうち、言語に特化したものです。

LLMを含むAIは、魔法のように推論や創造をしているように見えますが、コンピュータによる計算結果です。

およそどのLLMの解説本にも書いていますように、LLMは、インターネット上のテキストを学習して、与えられた単語（トークン）の次にはどの単語（トークン）が続きやすいかを確率的に判断して文章を生成します。

「吾輩は」と来たら「猫である」と続く確率が高いといった判断です。

LLMはこれに尽きます。

LLMは記号接地しておらずサールの中国語の部屋のようであるという、記号接地問題 ～AIは言葉の意味を理解できるのか？～ ｜NTS Journalで示唆されている見解に私も賛同します。

（２）私個人の捉え方

個人的には、LLMを、インターネット上の知識を備えたワープロのようなものだと捉えています。

ワープロが出始めた頃に活字の価値が急速に下がった違和感と、LLMが出始めた頃に流暢な文章の価値が急速に下がった違和感が似ているからです。

ワープロ登場以前の活字といえばしっかりとした重要な内容であること請け合いでしたが、ワープロが普及するとくだらない内容でも簡単に活字にすることができるようになり、混乱した記憶があります。

それと同じように、LLM登場以前は流暢な文章は内容も優れているだろうと推測できましたが、LLM普及後は流暢な文章でも内容の伴わないものが目立つようになりました。

その最たる例がハルシネーション（幻覚）と呼ばれる事実に基づかない内容です。

ワープロの普及期に活字の価値を補正したように、メールやレポートが流暢だからといって内容が伴っているとは限らないと流暢さの価値を補正しなければなりません。

ITエンジニア（プログラミング）の世界に限定すると、アセンブリ言語→コンパイラ言語→スクリプト言語と高水準の記述ができるようになってきた延長線上にLLM言語を位置づけています。

スクリプト言語が普及してもアセンブリ言語やコンパイラ言語がなくならなかったように、LLM言語が普及してもスクリプト言語はなくならないと読んでいます。

（３）LLMに適した仕事

インターネット上の情報を見放題で無限の時間を使えばできるような仕事がLLMに適しています。

アイデア出し、翻訳や要約など文章やフォーマットの整形、感情や分野の分類、定型的なプログラミングコードの生成などです。

司法試験の合格水準に達したと聞いても驚きはないです（インターネット上の情報を見放題で無限の時間を使えば司法試験に合格できると思うので）。

LLMは数学や推論が苦手だというのも、上記のLLMの捉え方からすると頷けます。

２．「正しさ」について

（１）一般論

上記のLLMの特性からすると、LLMが出力する内容が正しいとは限りません。

ハルシネーション（幻覚）は言うに及ばず、誰かが確かにそのような内容をインターネット上に書いているという事実水準では正しいとしても、その内容が正しい（真である）とは限りません。

よって、出力結果を見て自分で正しさを判定できない場合にLLMを利用するのは危険であると私は考えます。

推論や判断、政治学や経済学のような人文社会科学がそれに該当します。

逆に、出力結果を見て自分で正しさを判定できる場合には、安心してLLMを利用できます。

度忘れしてしまったけれども見たら再認できる内容や、文章に書かれた内容を表形式に変換するといった作業です。

プログラミングと、翻訳などの言語的なタスクについては微妙な点があるので以下で個別に論じます。

（２）プログラミング

プログラミングも動かしてみればすぐに結果がわかるので、基本的には出力結果を見て自分で正しさを判定できる場合に含まれると考えて差し支えないでしょう。

正しいプログラミングは動作するプログラミングです。しかし、逆は必ずしも真ならずで、動作するプログラミングが正しいプログラミングであるとは限りません。

例えば、動作はするけれども副作用があるプログラミングや、動作はするけれども非常に読みにくいプログラミングは、正しいとは言い難いです。

よって、LLMに頼り切るのではなく、LLMの出力を理解して微調整して使うべきだと私は考えます。

（３）言語的なタスク

多くの人が使っていてそれっぽく見える表現は正しいのだと割り切ってしまえば、言語的なタスクでLLMは大活躍します。

２つの似たような表現をGoogleで検索してヒット数の多い表現が正しいとするような考え方です。私は大学生のときに言語学関係の授業でそのような考え方に触れて衝撃を受けました。

英語（外国語）でビジネスメールを書くときにLLMに添削してもらい、あまり使われない表現をよく使われる表現に直してもらうといった使い方ですね。

他方で、出現頻度は高くないけれどもより適した表現があるのではないかという場面ではLLMに頼るのは避けたほうがよいでしょう。

親密な間柄でのメールや、内容を理解した上で英語（外国語）から日本語（母国語）へ翻訳する場合などは、出現頻度が高くても正しいとは限らないので、LLMの出力結果を丸ごと採用することにはならないでしょう。

３．自分がLLMを使う場合

この記事でのここまでの記述から想像できますように、私がLLMを使うのは、プログラミングでインターネットを検索して調べる手間を省きたい場合や形式の変換をしたい場合、一般的によく使われる言語表現を知りたい場合です。

具体的には、Pythonで日付のフォーマットを調整したいときや名前とメールアドレスのダミーデータがほしい場合、英文ビジネスメールで妥当な表現を知りたい場合などです。

私は実際にコードを書く時間がさほど多くないので、AIコーディングエージェントは使わず、ブラウザからChatGPTやGeminiを呼び出して使っています。

業務のうちで調査や設計、教育指導の占める割合が高く、LLMの恩恵をまだそこまで受けられていない（LLMに仕事を奪われない）印象です。

４．顧客にLLMを使ってもらう場合

顧客にLLMを使ってもらう場合は、API経由でLLMを呼び出すコードを書くのが私の仕事であることが多く、その点ではLLM登場以前の業務と同じです。

顧客はLLMを魔法のように何でも解決してくれるツールだと捉えていることが多いので、そうではないと説明するのも私の仕事です。

顕著なのはリアルタイムの情報で、普通にLLMを使うとリアルタイムの情報は使えないことを説明し、ブラックボックスではありますがAPIでオプションを設定することによりリアルタイムの情報を得るか、従来型のプログラムで情報を取得してからプロンプトに盛り込む（RAG）かを提案します。

顧客あるいはプログラミングスクールの受講生がLLMでプログラミングコードを生成したのはいいけれども、思うように動かなくて困ったと相談を受けることも多いです。そういうときは概念を整理しながら解決していきます。

現実的に妥当な設計をしてからLLMを利用するとたいていうまくいきますが、設計が曖昧なままLLMへの質問を繰り返すと道に迷いがちです。どれだけがんばってもHTMLだけでは本格的なウェブアプリは作れませんし、スマホ利用を想定するからといってSwiftとJavaで開発するのが最適解とは限りません。

ローカル環境だけでプログラムを書いたら、そのローカルPCの電源が入っていないときにプログラムの実行はできませんし、ほかのユーザーがインターネット越しにそのプログラムを呼び出すこともできません。

プログラムが小さい段階ではLLMの出力結果をよくわからないまま貼り付けても動いたのだけれども、プログラムが大きくなるにつれてコードがぐちゃぐちゃになり手が付けられなくなったという状況を目にすることもあります。変数名をわかりやすくして同じ処理は一箇所にまとめて繰り返さないといった、プログラミング学習にまつわる雑感（コーディング原則本等の自分なりのまとめ）で書いた内容を念頭にリファクタリングするのが私の仕事になることもあります。

ある程度の一般的なリファクタリングであればLLMに任せることもできるでしょうが、ビジネスに固有の命名であったり自分にとって最高にわかりやすい整理などは人力でしなければならないのではないかと感じます。

５．参考文献

LLMのプロンプトエンジニアリング : GitHub Copilotを生んだ開発者が教える生成AIアプリケーション開発 作　者：　 出版社：　オライリー・ジャパン 発売日：　2025年06月10日

LLMを原理的に説明してくれます。この記事は本書に依拠しています。

大規模言語モデルを使いこなすためのプロンプトエンジニアリングの教科書 作　者：　 出版社：　マイナビ出版 発売日：　2024年04月05日

Pythonのような従来から存在するプログラミング言語と合わせてLLMの全体像を把握するのに有用です。

プログラミング知識ゼロでもわかるプロンプトエンジニアリング入門 作　者：　 出版社：　秀和システム 発売日：　2025年04月30日

推論を重視した小手先のテクニックの紹介が多い印象ですが、LLMの特徴がわかります。

生成AIアプリ開発大全 : Difyの探求と実践活用 作　者：　 出版社：　技術評論社 発売日：　2025年04月10日

cronを使うとコマンドやスクリプトを定期的に自動実行できるので便利です。

自動実行ですから、少なくともエラーが発生した場合には通知を受け取りたいです（通知がないとエラーが発生していても気づかず放置してしまいがちです）。

cronで実行するスクリプト内に通知を行うコードを書くことが多いですが、そもそもそのスクリプトが実行されなければ通知もされません。

cronにはデフォルトでエラーを含む出力をメール通知する機能が備わっています。

しかし、外部にメールを送信できるようにサーバーを構築するのは面倒なので、slackに通知しようというのがここでの問題意識です。

その方法を調べると、いろいろなやり方が出てきて混乱したので、なるべくシンプルな方法をここにまとめます。

１．事前準備（slackに通知をするシェルスクリプトを用意する）

事前準備として、標準入力から受け取った内容をslackに通知するシェルスクリプトを用意します。

標準入力からの受け取りやjsonの組み立て、特にダブルクォートのエスケープに苦労しつつも、最終的には次のシンプルなシェルスクリプトに落ち着きました。

webhookurlはご自身のものを指定してください。

#!/bin/sh

webhookurl='https://hooks.slack.com/services/XXXXXXXX/YYYYYYYY/ZZZZZZZZ'
stdin=$(cat)
message=$(jq --arg text "$stdin" -n '{text: $text}')
curl -X POST -H 'Content-Type: application/json' --data "$message" "$webhookurl"

ここでは、このシェルスクリプトを、/usr/bin/local/slack_notification.shという名前で保存し、パーミッションを755に設定します。

２．ジョブごとに通知を設定する

ジョブの出力をパイプでslack通知スクリプトに渡せば、ジョブごとに通知を設定できます。

この記事では、実験のため、エラーが発生しないecho "cron slack test"とエラーが発生するnotexistingcommandを例に取ります。

標準出力と標準エラー出力の両方を通知するcrontabの例

* * * * * echo "cron slack test" 2>&1 | /usr/local/bin/slack_notification.sh 
* * * * * notexistingcommand 2>&1 | /usr/local/bin/slack_notification.sh

標準エラー出力だけを通知するcrontabの例

* * * * * echo "cron slack test" 2>&1 1>/dev/null | /usr/local/bin/slack_notification.sh 
* * * * * notexistingcommand 2>&1 1>/dev/null | /usr/local/bin/slack_notification.sh

３．一括で通知を設定する

cronで実行するジョブの数が少なければジョブごとに通知を設定すればよいのですが、たくさんのジョブをまとめて通知の設定をしたい場合は、cronにデフォルトで備わっているメール通知を活用すると楽です。

この方法では、メールの件名に実行コマンドが書かれているなど、詳細情報を取得できるという利点もあります。

postfixをインストールして、/etc/aliasesにcronslack: |"/usr/local/bin/slack_notification.sh"を追記し、newaliasesコマンドを実行します。

詳しくは「postfix　スクリプト」などと検索してください。

標準出力と標準エラー出力の両方を通知するcrontabの例

MAILTO=cronslack
* * * * * echo "cron slack test"
* * * * * notexistingcommand

標準エラー出力だけを通知するcrontabの例

MAILTO=cronslack
* * * * * echo "cron slack test" 2>&1 1>/dev/null 
* * * * * notexistingcommand 2>&1 1>/dev/null 

４．細かい話

crontabの実行結果をSlackで受け取る方法 | 北進総業と問題意識を共有していますが、私は既存のcronをなるべく変更せずにcronの記載自体から何をしているかわかるようにしたかったので、上に書いたような方法にしました。

【AlpineLinux】Cron(busybox)でMAILTOを指定してもメールが届かない件 – TokunagaKazuya.tkとか、sendmailコマンドを差し替えて、sendmailコマンドにくるメールをSlackに投稿する #Docker – Qiitaとか、cronの出力をメールでなくSlackに送る方法 #Slack – Qiitaとか、みなさんが書かれているいろいろな方法を参考にしました。

スクリプト言語に頼らずUNIX哲学に則った解決法を見出だせたのではないかなと思っています。