編集後記「どうする？ どうなる？ 解決！Python」と「何をもってPythonicなのか」：Deep Insider's Eye 一色＆かわさきの編集後記
かわさきからは「どうする？ どうなる？ 解決！Python」というタイトルでPython TIPS連載の今後についてChatGPTに聞いてみて思ったことについて、一色からは「何をもってPythonicなのか」というタイトルで執筆中に感じていた“Pythonic”という説明に対する戸惑いを解消するまでの体験談について書きました。
＠ITのDeep Insiderフォーラム【AI・データサイエンスの学びをここから】を担当しているDeep Insider編集部の一色とかわさきです。2月の初めに公開した編集後記から3カ月ぶりですね。
編集者が記す「あとがき」である、この編集後記では、執筆／編集時には書けなかった小話や裏話、感想、ぜひ読者にも知ってほしいという話などを書いています。
どうする？ どうなる？ 解決！Python（かわさき）
かわさきしんじ
かわさきしんじ大学生時代にIT系出版社でアルバイトを始めて、そのまま就職という典型的なコースをたどったダメ人間。退職しても何か他のことをできるでもなくそのままフリーランスの編集者にジョブチェンジ。そしてDeep Insider編集部に拾ってもらう。お酒とおつまみが大好き。通称「食ってみおじさん」。最近はすっかり「ダイエットおじさん」に変貌し、有酸素運動＋筋トレ＋カロリー制限のおかげで体重は62kgと63kgの間をさまよい中。体脂肪率も何とか20％を割り込んだかな？
以前にも編集後記で話題に挙げたことがありますが、現在、編集部内では「解決！Python」の将来について議論が交わされています。
どんな議論かというと、「GitHub Copilotなど、LLMを活用してコードを生成するチャットボットがエディタに統合されつつある状況で、わざわざWebを検索して解決！PythonのようなWeb記事（TIPS）に読者が集まってくれるのだろうか」というものです。
解決！Pythonのもともと次のようなコンセプトで立てられた企画です。
- Web検索から記事を見付けてもらうことが前提
- コード例を最初にまとめて配置し、必要なコードをコピー＆ペーストしてもらう
- 説明が必要な人はコード例の後にあるテキストを読む
Pythonそのものや各回で取り上げている言語機能やパッケージ、モジュールについてそれなりの知識があって、「取りあえず今はコードの書き方だけ分かればいいや」という人がメインの対象ともいえるでしょう。コード例を最初にまとめておけば、そうした人たちは必要な情報を得たら、すぐに自分の作業に戻れると便利ですよね。本文テキストはあくまでも知識や情報についても知りたいなと考える人たちへのおまけのようなものでした（そこにそれなりの手間や時間がかかっているわけですが）。
こうした意図で書かれた記事は、エディタに統合されたチャットボットに駆逐されてしまうかもしれないと筆者は考えています。例えば、以下の画像を見てください。
これはVisual Studio Code＋GitHub Copilotという環境で「日付をyyyymmdd hh:mm:ss形式で」表示する方法を対話形式で尋ねたところです。生成されたコードはエディタタブのカーソル位置に簡単に貼り付けられますし、そうすればコードを実行してそれが正しく動作するかも簡単にチェックできます。この方法を紹介する記事は「日付や時刻をYYMMDDhhmmssなどの形式に書式化するには」ですが、エディタ内で全てが完結するのであれば、わざわざWebを検索しようとは思わない方が大半なのではないでしょうか。
「なんだよ。あんたも使ってんじゃん」って？ いや、勉強のためにはインストールしないといけないじゃぁないですか。（かわさき）
専業プログラマーでもないのに、有償のGitHub Copilotをインストールして使ってるのは偉いよ。機械学習やデータサイエンスは定型のコードが多いので、そこまで調べることも多くないから、私はインストールしていないんだよね。一時的に使うならChatGPTでいいかってなる。定型コードが思い出せないなら、Google Colabで使えるAI生成機能（今なら期間限定で無料）も有用ですからね。（一色）
というわけで、ChatGPTさんに聞いてみましょう。解決！Pythonに未来はあるのかどうなのかを。
ChatGPTに慰められることになりました（苦笑）。つまり、解決！PythonなどのTIPS紹介記事であっても以下のような観点からは価値はあるということでしょう。
- ちゃんとした解説や背景情報が含まれていて、初学者にとって勉強になる
- 先進性があり、LLMがまだ学習していない情報が含まれる
- コードの正確性が保証されている
でも、それってTIPSを紹介する簡潔な記事というよりは、もっと読み応えのある記事ってことじゃない？ と思ったのは内緒。
まあ、LLMが生成するコードは、正しく動作するかどうかが保証されないということを認識しておくのは重要だと思っています。インターネットの世界には「ウソをウソと見抜けない人には……」という言い伝えもあるように、生成されるコードが正しいかどうかを見抜けるだけの知識と経験がないと、チャットボットを適切に活用できないのかもしれません。
解決！Pythonがこの先どうなるかはまだ分かりません。次第にフェードアウトするかもしれませんし、単なるコード紹介だけではなく、読者に興味を持って本文テキストまで読んでもらえるような内容に変えていくのかもしれませんし、はたまたプロンプトエンジニアリングTIPSに変わってしまうのかもしれません。いずれにしても、読者の皆さんのお役に立つのはどんな内容で、どんな構成の記事なのかをよーく検討しなきゃいけませんね。
結論はないのです。
こんな重大なことを、まずはChatGPTさんに気軽に聞いてしまうところに笑った。それはさておき真面目に感想を述べると、「コードの正確性が保証されている」というChatGPTの指摘には「なるほど」と思いました。これは確かに人間が書いた記事だから出せる優位性ですね。
しかし、ChatGPTの返答は「問題の解決」からズレているとも思いました。というのも、たとえ今より良質のTIPSを提供できたとしても、チャットボットなどによって解決！Pythonの読者が徐々に減っていく可能性を否定できないからです。いわゆる“ジリ貧”（ジリジリと次第に貧乏になることに例えた比喩）です。そのため、最近は編集スタッフの間で「“新しいこと”もしよう」という考えを共有しています。
その“新しいこと”の結論はまだ出ていません。さまざまな案は出ていますが、決定には至っていません。読者の皆さんからもアドバイスがあれば、この記事に対してSNS（はてなブックマークやX）でのコメントをぜひお願いします。なお、未来においても、解決！Pythonの読者がゼロになるわけではないので、かわさきさんには既存記事をメンテナンスしつつ、できればほそぼそと長く続けてほしいと思っています。
よろしくお願いします。
何をもってPythonicなのか（一色）
一色政彦（いっしきまさひこ）
＠ITのDeep Insider編集部の編集長。最近、「ウラ漫 ―漫画の裏側密着―【小学館マンガワン】」というYouTubeチャンネルをよく見ています（紹介動画）。このチャンネルの目的の一つは「こういう編集者と一緒に仕事がしたい」という人を増やすことのようです。分野は違えど私も「編集者」なので、さまざまな刺激を受けています。特に、漫画家との打ち合わせや、編集部内の会議や合宿など、他業界／他社の白熱した議論の様子を見ることができるのは新鮮で、興味深いです。ちなみに、副編集長の回が特に人気のようです。
読者の皆さま、いつもご愛読ありがとうございます。今回の編集後記は、過去の記事執筆中に少し引っ掛かっていたことについて書こうと思います。ちょっと長くなりますが、もしよければ、私が「どんなふうに調べて考えたか」の体験談を面白おかしく読んでもらえるとうれしいです。
ディープラーニングや最近の生成AIを実装する際には、PyTorchというライブラリがよく使われていることは、この編集後記の読者であればご存じかもしれません。このPyTorchは“Pythonic”である（つまりPythonらしい）ことを自称しており（参考例）、ユーザーからも“Pythonic”であると評されています。私自身も2020年に執筆した記事で、PyTorchの代表的な特徴の一つとして「Pythonic： Pythonのイディオムをうまく活用した自然なコーディングが可能」と記載しました。
とはいえ、ずっとモヤモヤしていました。情報をどれだけ探っても、どんなドキュメントを読んでも、“Pythonic”の説明や基準は曖昧模糊（あいまいもこ）としており、具体例を伴って厳格に説明されている資料は、ほぼほぼ見つけられませんでした。よって自分で上記のように書いておきながら、絶対的な確信を持てない戸惑いを感じていたのです。
「この戸惑いを解消したい」という願望から「Pythonicとは？ Pythonらしい書き方の極意」という原稿を半分くらい書いたまま、長らく放置してきました。その一部を今回の編集後記に反映しつつ、その原稿自体はボツにして、きれいさっぱり削除しました！（苦笑）
こ、これは！ 下手すると炎上案件かも？（笑）
ステップ1. ググる：「Pythonicとは何か？」
まず「Pythonicとは何か？」をGoogle検索に聞いてみることにしました。こういった文章的な疑問は、英語のStack Overflowなどの掲示板で回答が見つかることが多いです。やっぱり日本語の情報は量も質もイマイチです……ので、私は基本的に英語で検索します。そこで「What is Pythonic？」と英語で聞いてみました。
結果としては、Built InやUdacity、Stack Overflowが上位にヒットしました。それらのコンテンツでは、「The Zen of Python」（Pythonの禅、別名：PEP 20）という原則や、「PEP 8」というコーディング規則に従うことと、タプルやリスト内包表記といったPython特有の構文を使うことが、“Pythonic”であることの基準として掲げられていました。
コードを書いていて、たまーに「Pythonぽくないなぁ」って思って書き直すことはありますよね。具体例はすぐには出てこないんだけど。これはPython脳で考えてないってことなのかも。
ちなみにThe Zen of Pythonは、import thisというPythonコードに対する出力でいつでも参照できます（このような隠しコマンドで表示される画面を「イースターエッグ：Easter egg」とも呼びます）。下のリスト1がそのPythonコードと実行例ですが、出力されるテキストは英語で、しかも抽象的な内容なので、より詳細な説明はこちらの記事にお任せします。
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
先ほどのPythonicに関する説明には「確かに」と思いましたし、私が書いた特徴の説明にも通じます。しかし自分の中では、まだスッキリしていません。どちらかというと、これらはコードを書く人がPythonらしく書くために守るべき原則／規則／構文であるように感じます。微妙に違うんです。PyTorchというライブラリが「“Pythonic”である」と評される、明確な基準や根拠が知りたいのです。
しかも例えば「The Zen of Python」の1つ目の「醜いよりも美しい」という原則は、主観的な側面もあります。原則は、ある程度の判断基準にはなり得ますが、それだけで“Pythonic”とは明言しづらいと感じました。
ステップ2. チャットAIに質問：「Pythonicなライブラリを教えて」
そこで次に、Pythonicなライブラリにはどんなものがあるかを調べ始めました。直感的に、「Pythonic library」などと検索しても適切な回答がヒットしないと予想して（※事後に確認しましたが、やはりヒットしませんでした）、チャットAIサービス、具体的にはChatGPT／Gemini／Claude／Perplexityの4つに全て同じ質問を入力して、回答内容を比較しました。
こういうときが、チャットAIの使いどころだよね、と思います。が、シチュエーションを含めて説明が難しいし、なかなか人に理解してもらえません……。
4種類のLLMによる合議制で正解を決めるなんて、某アニメに出てくるスーパーコンピュータみたいです。
それぞれのチャットAIに「PyTorch以外にも『Pythonicだ』と言われるライブラリがあれば教えてください」と質問したところ、いずれでもNumPyやpandasなどが挙がりました。確かに数値計算ライブラリの「NumPy」は、Python言語のリストの構文に通じるところがあり、「ほとんどPython言語の一部」と言っても過言ではないと私自身は思っているので、Pythonicであることに同意します。また、NumPyスタイルのAPIを持つ、データ分析ライブラリの「pandas」もPythonicで間違いないでしょう。同様の理由で、大規模な数値計算＆機械学習ライブラリの「JAX」もPythonicです。
それでは、PyTorchはどうでしょうか？ 同じ理屈で「Pythonic」と明言するのは、ちょっと違う気がします。特にPyTorchが登場した2016年8月から、TensorFlowと市場シェアが拮抗（きっこう）していた2020年ごろまでは、TensorFlowを意識して、PyTorchは「TensorFlowよりもPythonらしくて使いやすい」という意味合いで、“Pythonic”であると評されていたのだと想像しています。この想像が正しいとするなら、Pythonicであることを明確化するためには、PyTorchとTensorFlowの違いに着目する必要があると考えました。
ステップ3. チャットAIに質問：「PyTorchはPythonicで、TensorFlowはそうではない？！」
続けて、「かつて『PyTorchはPythonicだがTensorFlowはそうではない』という主張があったのを覚えています。これについてはどう考えればよいでしょうか？」とチャットAIに質問しました。その返答をまとめると、「この主張は特にPyTorchとTensorFlow 1.xの設計哲学の違いに基づいており、現在のTensorFlow 2.xではPythonicへの改善が進んでいるので、いずれもPythonicな部分とそうでない部分がある」とのことでした。私の考える両ライブラリの性質にも合致しているので、設計哲学の違いが主張の根拠だろうと、これまでより強く納得しました。具体的に説明していきます。
1.x時代のTensorFlowでは、静的な計算グラフをベースにする設計思想で作られており、そのためセッションという特殊な実行方法（「define-and-run」とも呼ばれる）を学ぶ必要がありました（参考連載）。これに対してPyTorchは、動的な計算グラフで通常のPythonプログラミングと同じように実行できる（「Eager Execution：即時実行」や「define-by-run：実行しながら定義」とも呼ばれる）ため、実行途中にブレークポイントで停止してデバッグすることも可能です（下の画面はその例です）。
PyTorchを使うコードに対して設置したブレークポイントで実行途中に停止してデバッグしているところまた、TensorFlow 1.xでは、関数を順番に呼び出していく手続き型アプローチが一般的でした。これに対してPyTorchは、特に複雑なアーキテクチャのモデルを定義する場合には、上の画面のようにクラスを定義するオブジェクト指向アプローチをよく採用します。これを可能にするAPIデザインが“Pythonic”であるとする説明が、一部のチャットAIの返答に含まれていました。
しかし、TensorFlowがバージョン2.0になると、Eager Execution（つまり動的な計算グラフ）がデフォルトで有効となり、TensorFlow標準の高レベルAPIにKerasが採用されたおかげでクラス定義によるオブジェクト指向アプローチも実装しやすくなりました（参考記事）。これによってTensorFlowもかなりPythonicになっている、と全てのチャットAIの返答に示されていました。さらに、あるチャットAIの返答には、「“Pythonic”を巡る議論は重要ではなくなっている」とも書かれていましたが、その意見は私の考えとも一致するので、納得しました。
ただし、最初から“Pythonic”を目指して設計されてきたPyTorchの方が、Keras（TensorFlow 2.xバックエンド）よりも“Pythonic”であるのは間違いないとも思いました。またKerasを使わないTensorFlow 2.xの低レベルAPIと比べるなら、確実にPyTorchの方がPythonicです。
まとめると、「PyTorchは“Pythonic”である」という主張は、特にかつてのTensorFlow 1.xとの比較において、動的な計算グラフ（Eager Execution）とオブジェクト指向アプローチという2つの特徴のおかげでよりPythonらしくコーディング可能であったことを指すが、現在のKeras（TensorFlow 2.xバックエンド）では、それらの特徴をサポートしたため、TensorFlowもよりPythonicになってきており、“Pythonic”を議論することは重要ではなくなっている、ということです。ただし、PyTorchは最初の設計思想から一貫して“Pythonic”を目指しており、“Pythonic”がPyTorchの代名詞となっている、ということも付け加えておきます。
以上の結論を出し、自分の中で折り合いを付けました。
余談ですが、Kerasもバージョン3になって変化が起きているので、近いうちにアップデート情報のニュース記事を書こうと思っています。また、『PyTorch入門』も最新のバージョンでも動くかどうかを検証して改訂しなくてはいけないと思っていますので、これもできるだけ早く手を付けたいです。
Copyright© Digital Advantage Corp. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。