以下のテキストは結城メルマガVol.577からの抜粋で、図版やプログラムへの参照などは省いています。
Model: GPT-4
Date: 2023-04-19
次の文章を日本語の一文に要約してください。
"2023年2月頃にTwitterでいわゆる「凍結祭り」がありました。理由がよくわからないままにアカウントが使えなくなる（凍結される）人が続出したのです。原因はどうやらTwitter APIの不適切な利用らしいのですが、それに該当するとは思えない人まで凍結されています。
結城はその際に、アカウントが凍結されるのを防ぐために多くのbotや自作サービスを停止しました。何が原因で凍結されるかはっきりしないので万全を期したという理由もありますし、昨今のTwitterの動きが不穏なので、この機会に整理しようと思ったという理由もあります。
匿名で質問を受け付ける自作サービス「結城浩に聞いてみよう」もその際にいったん停止しました。これはTwitter APIに大きく依存したWebサービスの一つだからです。
それから二ヶ月近くが過ぎたので、停止していた「結城浩に聞いてみよう」を再起動したいと思ったのですが、「どうせならこの機会にTwitterへの依存度を下げた実装に変更したいな」と考え、実行しました。
せっかくなので、どんなふうに考えたのかをまとめてみようと思います。といっても、私の自作プログラムの内容を細かく書いてもしかたがないので、技術的な詳細には触れません。ですから、プログラムにそれほど詳しくない人でも読めると思います。"
2023年2月の「凍結祭り」で不明な理由でアカウント凍結が相次ぎ、結城は自作サービスを停止。匿名質問サービス「結城浩に聞いてみよう」も停止し、再開時にTwitter依存度を下げる実装に変更。プログラム内容を分かりやすくまとめる予定。
同様に一文で要約してください。
"askは一般のユーザさんから質問を受け取り、結城がそれに対してTwitter上で回答するというサービスです。質問は画像化されて結城の回答と共にTwitterに投稿されます。その投稿にTwitter APIを使うわけです。
ではaskをどう修正していけばいいのでしょうか。結城は以下のような図を描きながらあれこれ検討しました。
最終的に、今回のaskの修正の大方針は「TwitterからMastodonへ」として考えました。これまでTwitter APIを使って投稿した部分をそっくりMastodon APIに置き換えてしまえばすぐに修正できると思ったからです。Twitter APIを使わないといってもaskのプログラムをすべてゼロから作り直すのは賢明ではないと考えたのです。
さらに考えているうちに、世の中にはすでにtootという名前の、Mastodonを使って投稿するプログラム（CLI）が存在することを思い出しました。私がわざわざMastodon APIをプログラムで直接呼び出す必要すらありません。askの中からtootというプログラムを呼び出せばいいからです。すでにちゃんと動いているプログラムがあるのだから、それを活用するのはいいことです。
結城はこれまでにtootを利用してMastodonにアクセスするプログラムをいくつか書いてきました。その経験は、今回のaskの修正を検討する上で大きく役立ちました。さらに過去の成果物として作った、現役で動いているコードが手元にあるのも頼りになりました。
よく思うことですが、普段から新しい技術（サービス、ツール、プログラム、……）にちょっとだけでもいいから触れておくと、いざというときに助かります。たとえば今回のように「Twitterの代わりになるサービスを使いたい」と思ったときに、すぐに使えるMastodonアカウントがあり、Mastodonにアクセスする小さなプログラムが手元にある状態になっているからです。
たとえ、その小さなプログラムがそれ単体では大して役に立たなくてもいいのです。実際に動くコードがあるということ自体が、新しいプログラムを作るときの手間を大きく削減してくれるからです。"
askサービスの修正では「TwitterからMastodonへ」方針で、既存のtootプログラムを活用。普段から新技術に触れておくことが、状況変化時に役立つと結城が感じる。
"今回の修正を一言でいえば「Twitterに投稿する部分をMastodonに置き換える」だけのことです。
若いときには、このくらいの修正はちょちょいのちょい……という感覚で作れたのですが、最近はなかなかそうはいきませんね。何時間も続けて作業できるほどの集中力はありません。
ですから最近は「ステップ・バイ・ステップ」を強く意識しています。段階を踏んで考え、段階を踏んで作っていくということです。そしてその際には不完全でもいいので考えたことをしっかり書き留めながら進みます。続けて作業できない上に記憶力もないからです。
たとえば今回のaskを最初に作ったのは何年も前のことですから、プログラムの詳細はすっかり忘れています。ですからプログラムを読むところから始めます。また、自分の考えを整理するため、ユースケースをLogseqに書き留めていきます。
また、プログラムをいきなり修正して動かすのではなく、まずは自分が考えた処理の流れを手動で実行するのも行いました。処理の流れというのは、ユーザが質問し、結城が回答し、その回答がMastodonに流れ、それをTwitterで紹介するという一連の動作のことです。自分の手でいったん実行することで、手順をよく理解することができるからです。手動で実行できたなら、あとはその手順をプログラムに行わせればいいのです。
ところで「その手順をプログラムに行わせればいい」というのは正しいのですが、実際に修正して動かしてみると問題はいろいろ見つかります。その場合でもあわてて修正するのではなく、問題点を整理するステップと、一つ一つ修正して確認するステップを踏んでいきます。
そんなふうにしてプログラミングを進めます。"
今回の修正は「Twitter投稿をMastodonに置き換え」。集中力や記憶力が低下したため、「ステップ・バイ・ステップ」で進め、考えを書き留め、手動実行で理解を深め、問題点を整理して修正。
"プログラミングではChatGPTの助けを何回か借りました。自分で検索すればすぐにわかりそうな場合でも、意識的にChatGPTに尋ねた部分もあります。それは「私が気付く解決法とは別の解決法」をChatGPTが提案してくれることがよくあるからです。
たとえばRubyでファイルを読み込むとき、私はいつもUTF-8指定を忘れてエンコーディングエラーを引き起こすのですが、それについて尋ねたときの対話が以下です。なお、ChatGPTに尋ねたあと、念のためWeb上にあるRubyの公式リファレンスを確認しています。
また、基本的なHTMLの話題でページ内ジャンプのアンカーの書き方をいつも迷うので、それについてもChatGPTに尋ねてみました。ただし、鵜呑みにせずにMDNのWebサイトで確認しています。
Rubyの基本的な文字列の切り出しについても尋ねてみました。「そういえば、そういうのもあったなあ」と忘れていた記憶がよみがえります。
ChatGPT相手なら、どんなに基本的な質問を投げてもご機嫌で回答してくれるのでいいですね。
ただし、ときどき間違ったことを教えてくるので、必ず自分で公式ドキュメントなどで確かめることが必要です。
たとえば以下の対話では、いろいろ誤ったことを教えてきました。しかし、有用なライブラリの存在を教えてくれたので、それを手がかりに公式ドキュメントを読むことができました。知らないライブラリだったので助かりました。"
プログラミングでChatGPTを利用し、解決策を提案させたり基本的な質問に答えてもらった。役立つ情報もあるが、間違いもあるため、公式ドキュメントで確認が必要。知らないライブラリの存在も教えてくれて助かる。
すべてつなげてみると以下のようになる。確かに要点はとらえている。