生成AI時代のプログラミング学習

今のプログラミングを取り巻く環境

Codex や Claude Code、Antigravity など昨今は普通の言葉でAIに指示することで、プログラムを作成してくれる環境が整ってきています。例えば「クイックソートのプログラム作って」ぐらいでもソートのプログラムを作ってくれます。素晴らしい、……と同時にちょっとおもちゃを取り上げられた子どもの気分にもなっちゃいます。さて、こんな状況で今の学生たちは果たして「プログラミング言語」を勉強する必要があるんでしょうか? はたまた、勉強するとしたら何を勉強したらいいんでしょうかね。

そんなことについて考えていて、最近1つの答えが出たので書いて見ようと思いました。

よく見かけること

数年前に生成系AIがコードを吐いてくれるようになり、プログラミング言語の知識がなくてもプログラムを作成して実行できるようになりました。(まあ実行するには本当に多少知識は必要でしたが) これについてQitaで面白い記事を見かけたことがあります。

僕はプログラミングが嫌いだったんだけど、おかげで嫌いなプログラミングをせずにプログラムが書ける

これは本当に素晴らしいことだと思う。プログラミング言語の知識やアルゴリズムの知識がなくても、それを形にできる。……僥倖……まさに僥倖! といってもいい。プログラムが苦手、嫌い、そもそもできない、そんな人達がプログラムを作成することに関われるまたは利用することができる。単純に裾野が拡大し、利用者が増えて、コンピューターがもっと一般的に本当の「利用できるもの」になる。いや、ほんといい時代になったもんです。この事自体は僕は全肯定です。

しかしそんなプログラミングを「教える側」や「教わる側」は色々と思うところがあるようです。特に教える側。言ってみればこの現状は教える側にとっては今までやってきたことの全否定にもなりかねません。そうしたことをふまえ、次のような意見が多かったように思います。

  • AIが生成したコードのコードレビュー (本当に目的のコードになっているか読む) ができるぐらいはスキルが必要
  • どういう構造でソフトを構成するかのアーキテクトの知識は必要

確かに最終的にはその成果物の責任を人間が負うわけなので、コードレビューは必要かもしれません。しかし昨今は16年近く見過ごされたバグをAIが発見したり、LinuxのコードのバグをAIで探して報告してくる人たちに、その件数が多すぎるがゆえにLinus Torvaldsが「バグを送りつけてくるならパッチも一緒に送ってこい」とブチギレする事態にもなってます。つまり人間のコードレビューが信用できるのかというとすでに疑問符が付く状態です。

またアーキテクトレベルの設計の話ですが、これは多少は理解できる点はあります。データベースを使ったシステムにするのかどうか、SQliteでいいのかMySQLレベルのものが必要なのかどうか。そんな実際の実装を選定する能力や、比較対象としてどんな物があるのかを知っておく必要はあると思います。AIはいわゆる「よく使用されるシステム構成」を提案するわけなので、実情に合わせた実装選定というのは必要かもしれません。ただしかし、これらのいわゆる「設計前提」もMarkdownファイルに書いておけば、AIはそれを考慮して提案してくれる状況になりつつあります。きちんと前提を記述して「そのうえで考えられる適切なシステム構成をMarkdownで書いて」と投げれば、上流工程でさえ人間は手を出す必要はないのかもしれません。

じゃあプロンプトやMDファイルを作れたらいい!!

タイトルの通り、これまでのことを考えると - AI に必要な情報を整理して与える - AI にやってもらいたいことを明確に与える これさえできればもうプログラミング知識やスキルは必要ないように思います。そう多分必要ないんです。きちんと必要な基礎情報と守るべき条件などを与えれば、それに応じてコーディング、デバッグ、テスト、場合によってはデプロイまでAIエージェントはやってくれる状況になっています。また上記の2つの項目に必要な能力はプログラミングスキルではなく、情報収集能力だったり、情報整理能力だったりします。

「いやその情報を取ってきて整理するためには情報処理のスキルが必要だ」

まあそういう意見もあるかもしれません。ただ現実として、「どのような情報を取ってくればいいか」と聞いたり、「要件定義のために必要な項目を提示」などとAIに言えばそれもやってくれる現実があります。 つまり、情報処理に関わってきた人間が今まで培ってきたさまざまなノウハウやスキル、そういったものは本当に「代替できる」時代になってしまったわけです。これを認めなければならないと思います。まさに、自動車が発売されたときに馬車を作ってた人みたいなもんです。悲しいけどね。

なんか勉強することあるの?

こういう時代、プログラミングについて人間はそれについてなにか勉強する必要があるんでしょうか。おそらくもう1,2年もしたらないんだと思います。AIに指示し、実行環境を構築してもらい、実行する手順を作ってもらって、デバッグ、テストもやってもらう。こういうことになるんだろうと思います。これに似た状況として言えそうなのは、コンパイラができたときのマシン語職人のようなものかと思います。現代のプログラマーというのはマシン語でプログラムを書くことは特殊な状況でない限りはほぼやりません。おまけにコンパイラが何やってるかをすべて把握している人はほぼいません。(コンパイラを作ってる人は別ですが) このおかげで僕らはマシン語を特に理解することなくコンピューターをプログラムで動かすことができていました。そう、マシン語を勉強することなくです。

現代はこのマシン語が高級プログラム言語になり、そのときのプログラムコードが自然言語になったわけです。つまり今のAIは自然言語コンパイラという事かもしれません。 (たしかに決定論的な出力ではないというのはわかりますが、現実こうなっちゃってるってことで)

しかしここにヒントがあると思っています。きちんと情報について勉強してきた人たちは、この「マシン語がなにか」も理解しています。そしてそこから勉強に時間をかければ「マシン語で」プログラムを書くこともできるはずです。これが勉強するべきことではと。

つまりなに勉強するの?

現代のプログラムに係る人たちが勉強すべきまたは身につけるべきスキル水準はなにかというと、「今から勉強すれば多少時間はかかってもそれを再現できるためのスキル」だと思います。例えばずっとAIだよりでプログラミングとはなに? 条件分岐?まったくわかりません、という人に「時間をあげるからこのAIが生成したプログラムと同じものを作成して」といわれると、AIの助けを借りたとしてもかなりの時間がかかるでしょう。まず何から勉強したらいいのか、どうしてそれを勉強するべきなのか、そういったものの検討がつかないと思います。当然そこから勉強したらいいということも言えますが、そこで向き不向きが出てきたり、AIに何からどう勉強したらいいかどう聞いたらいいかわからない、提案された勉強の方針の意味がわからない、など「とっかかり」が 0 というのは再現性という意味では問題です。なぜならその試行錯誤を廃するのがスキルだからです。

僕の結論としては、基本的にプログラミングスキルを現代で習得する必要はない、これが結論です。 しかし何をどこまで勉強するべきか、は現代のシステムがどのように動いているのか、は理解する必要があると思います。つまり「いざとなったとき勉強さえすればそれを再現できる」程度のスキルということです。まだ現時点ではCodexをどう使えばいいか、などのスキルは必要ですが、徐々になくなっていくでしょう。それが進んだとき、「さあAIの作ったコードを理解してみよう」としたときに「え?どうやってですか?」は技術の再現性が失われていてこれは回避する必要があります。なんだか伝統工芸の伝承方法みたいですね。

懸念

おそらく今後AI生成のコードがメインになっていくでしょう。その場合、以前まであった新しい言語がたくさん生まれたり、プログラミングの新しい概念が生まれたりということは減っていくと思います。確かに初期は言語をAIといっしょに作成するなんかのことが起きて増える事があるかもしれません。しかし、徐々にそれはなくなっていくんだと思ってます。AIは現在あるデータから学習し、生成するものなので、概念レベルの新しいものを作り出すのはなかなかに難しい気はします (できるようになるかも)。そうするとAIの性能そのものがIT技術の上限を決めてしまうのでは?という懸念はあります。人間は定理の外の公理を作るようにしないといけないのかもですね。

古くなったドライイーストの復活方法

古くなったドライイースト (冷凍庫で消費期限+5年とか) でも完全に死んでない限り復活できます。
ただし、袋の中のイースト菌が弱っていることには変わりが無いようです。
そこで『世代交代』させることで復活できます。

イースト菌の寿命はおおよそ24時間で、新世代が生まれる時間は約2~4時間だそうです [1]。
またイースト菌が一番楽に餌とできるのは単糖類 (ブドウ糖) です。
世代交代をさせ、新しいイースト菌を発生させれば、力のあるイースト菌として使うことができます。

方法
  1. 25~30度程度の水に古くなったドライイーストブドウ糖を入れる。
  2. 常温で2~4時間放置。これで一応次の世代がもとと同じ量生まれているはず。

ブドウ糖はドラッグストアの飴コーナーなどに売ってます。

[1] 鈴木 昭紀, 「酵母の増殖」, 日本釀造協會雜誌, Vol.69, No.1. pp.21--24, 1974.

ChatGPT Team Planの課金システムの話

ChatGPT Team Planの支払プランは2通り。

  • Frexible : 月額払いプラン。$30/m
  • Annual : 年額払いプラン。 $25/m

OpenAIでは支払方法がクレジットカード決済しかありません。月額払いプランの場合、3月分の支払が4月になります。
単年度決算上の経費で運用する場合はこの年額払いプランが使いやすいです。

この上で使用する前に気になっていた点をいろいろと試したので、残しておこうと思います。

月額払いプランの決済時期は?

月額払いプランにかかわらずサブスクを有効にした (カードで支払った) ときから、購入した期間が有効期間になります。
単純に言うと、1月10日に契約すると、2月9日までが有効期間になります。

契約は自動更新されるのか

自動更新されます。その前に解約すれば良いです。

有効期間中に解約するとどうなるのか。

有効期間中は使用できます。

2 シートから契約できるが契約するとどうなるのか。

Teamは2シート (2名)分から契約可能です。1人分という契約ができません。誰か知り合いを誘いましょう。
契約すると2名が使用できる「ワークスペース」が作成されます。
2シートのうち1名分は支払者が使用するため、ほか1名が追加で使用できる状態です。
残ったシートにはメールで誰かを招待することができます。

支払は誰がするのか。

ワークスペースを作成した契約者 (オーナー) が全員分支払をします。

招待された人はどのような手続きで利用可能になるのか。

招待メールに登録可能なリンクがあり、そこから手続きができます。
必要な情報は使用者のメールぐらいです。
Plusを利用するときのように、電話番号やクレジットカード情報は必要ありません。

シート数以上を招待したら何が起こるのか。

有効期間中にシート数を超える招待を行うと以下のようになります。

  1. シート数を超えて追加で加入した人が使用した日数の日割りでその追加された人分の月の料金が決められます。
  2. 追加料金は参入した日の次の支払日に加算されます。
  3. 次の支払日に追加された人が使っていると、その分ワークスペースのシート数が引き上げられます。途中で使用者から削除されていた場合はその使用した日数に応じた追加料金のみが加算され、ワークスペースのシート数は変わりません。

ワークスペースの中で他人のChat内容が見られるか

同じワークスペースでも基本的には見えません。共有することはできます。

ワークスペース内のユーザー管理はどのようになっているか。

ユーザーロールは以下の3つです。

  • オーナー : ワークスペースのオーナーでフル権限があります。
  • アドミン : オーナーに準ずる権限があります。支払関連のみ操作ができません。
  • メンバー : 他のユーザーロールの変更を行ったり、支払関連の操作などができません。(ただし招待はできる)

※ 現時点でも分からないのは「他のユーザーをオーナーにすると何が起こるのか」

途中で月額払いプランを年額払いプランに変更できるか。

多分支払日を境に可能だと思います。やったことないです。

以上です。とりあえずFrexible Planで契約して、すぐにキャンセルをすることで自動更新されずに1ヶ月だけ使用できます。ただし途中でシート数以上の招待を行うとその支払は次月になるので注意してください。

VBAでファイルを開くようなEXCELのファイルをOneDriveのフォルダに置いたとき

  • OneDriveの設定メニューに「ファイルのコラボレーション」がない

その場合、

キー:HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\OneDrive
名前:EnableAllOcsiClients
DWORD値:0

でThisWorkBook.Pathがローカルパスになる。
(ない場合は作れば良い)

ただし、オンラインバージョン履歴管理機能はOfficeソフトからは使えない。
でもOneDriveにあるからいらん。

Tikzで斜交座標のグラフを書く

Tikzとか余り使ったことがないので拙いコードですが、
こういうのが意外とWeb上になかったので載っけます。
特に座標の型と数値型の取り扱いにハマりました。
例えば、ベクトルvのスカラーk倍なんてのはCalcライブラリで

\pgfmathtruncate{\k}{5};
\coordinate (v) at (2,3);
\node at ($k*v$){$k*v$};

なんてできるんですけど、
coordinateされたvから座標を取り出した値は「2.pt」のように単位がついて普通の数値としての計算がしにくくなります。
たとえば以下のコードはコンパイルが通りません。

\pgfmathtruncate{\k}{5};
\coordinate (v) at (2,3);
\path let \p1=(v) in node at ($\x1*v$){$k*v$}; %\x1は\p1のx座標。ただし、\x1が純粋な数値でないので掛け算できません。

座標型から元の数値型のデータが取り出せたら苦労しないんですが、
どうやら方法が見当たらないんです。

そんなこんなで以下のコードのようになりました。
コンパイルはTexLive2022のLualatexでやりました。

左下からの原点の位置 \ox, \oy でグラフ内の原点の位置が決まります。
基底ベクトル e1, e2 で斜交座標の形が決まります。
そして、グラフの幅 \gx、グラフの高さ \gy でグラフのサイズが決まります。

使う場合はこのあたりを変更すれば良いです。

別のベクトルを追加する場合は、

\draw[->] (O) -- ++($2*(e1)+3*(e2)$);

のように、原点からの基底ベクトルを使った合成で座標を決めると綺麗だと思いますん。

\documentclass{ltjsarticle}
\usepackage{tikz}
\begin{document}
    \begin{tikzpicture}[scale=0.7]

        \coordinate (OO) at (0,0);

        %Origin Point coordinate
        \pgfmathtruncatemacro{\ox}{1}; % x
        \pgfmathtruncatemacro{\oy}{1}; % y

        %Basis Vectors
        \coordinate (e1) at (1,1); % x direction
        \coordinate (e2) at (0,1); % y direction

        %Graph size
        \pgfmathtruncatemacro{\gx}{5}; %width
        \pgfmathtruncatemacro{\gy}{5}; %hight

        %main
        %%Draw origin point label
        \path
            let \p1=(e1) in
            coordinate (e1o) at ($(\ox*\x1, \ox*\y1)$);
        \path
            let \p1=(e2) in
            coordinate (e2o) at ($(\oy*\x1, \oy*\y1)$);
        \path coordinate (O) at ($(e1o)+(e2o)$);
        \node at ($(OO)+0.5*(O)$) {$O$};

        %Draw grid
        \path
        let \p1 = ($(e1)$) in
        coordinate (e1e) at ($\gx*(\p1)$);

        \path
        let \p1 = ($(e2)$) in
        coordinate (e2e) at ($\gx*(\p1)$);

        %%v line
        \foreach \i in {0,...,\gx}{
            \draw[gray!40]
                let
                    \p1 = (e2)
                in
                    ($(OO) + (\i*\x1,\i*\y1)$) -- ++($(e1e)$);
        };

        %%h line
        \foreach \i in {0,...,\gy}{
            \draw[gray!40]
                let
                    \p1=(e1)
                in
                    ($(OO) + (\i*\x1,\i*\y1)$) -- ++($(e2e)$);
        };

        %Draw axis
        \draw[->,thick]  ($(OO) + (e2o)$) -- ++($(e1e)$);

        \draw[->, thick] ($(OO) + (e1o)$) -- ++($(e2e)$);

        %added vector
        \draw[->] (O) -- ++($2*(e1)+3*(e2)$)node[right]{$v$};
    \end{tikzpicture}
\end{document}
e1=(1,1), e2=(0,2) の斜交座標

修理用電子部品通販 Witrigs での購入と不良品

Witrigsとは

Witrigsは修理用の電子部品を取り扱う中国の通販サイトです。

Witrigsでの購入

今回はPixel3用のディスプレイパーツを購入しました。
購入方法は、Webサイトから購入します。
支払いについては、中国サイトにクレジットカードを入力するのは怖かったので、Paypalを利用しました。
なお、購入にあたってWitrigsにユーザー登録はしませんでした。
しかし、その後にアカウントがないことで色々と面倒が発生したので、
アカウントを作成して購入したほうがいいと思います。

購入後に送られてくるメールとして、

  • Paypalからの支払い領収書
  • Witrigsから購入明
  • Witrigsから注文処理明細

の3つが大事なメールです。
特にWitrigsからの注文処理明細には、役に立たない商品追跡番号と、
「注文番号」が書かれています。
なお、これらWitrigsからのメールは高確率で「迷惑メール」として分類されます。
注意してください。

Paypalとは

Paypal社 (米) が行っている支払い仲介サービスです。
仕組みは、消費者→Paypalに支払い、Paypal→業者に支払い、というものです。

物品の到着まで

到着まで約1ヶ月かかりました。
コロナの影響でコンテナ船や物流が逼迫していることが原因だそうです。

物品の保証期間

Witrigsで購入した製品には保証がついています。
どの時点からかは不明ですが、通常だと60日が保証期間だそうです。
今はコロナの影響で配送が遅れているので、保証期間が90日となっています。
(保証は発送から計算かな?)
なおこの情報はWitrigsの英語サイトにしか記述されていません。

物品が届いてから動作確認まで

今回物品が届いてしばらくしてからテストを行いました。
なかなか時間が取れなかったのもあり、物品到着から3週間ぐらい経っていました。
品物には「Witrigs Certifyシール」がはられているので、
剥がさないように動作チェックをしましょう。
今回のパーツを動作チェックしたところ、タッチパネルが操作できない不良品でした。
うあー。

物品について

到着したディスプレイパーツを見ていると、刻印に「LG 2018年製造」とありました。
おそらく発売当時に作られた「余剰品」と検品で不適になった「初期不良品」が混ぜられて、
市場に流通しているものと考えられます。
届いた製品には一応「Witrigs Full Check」とか書かれたシールが貼っていましたが、
おそらくチェックなどされていません。

返品などの交渉

Witrigsでの返品や交換はすべて「公式サイトに書かれているサポート用メールアドレス」にメールを送って対処されます。
公式サイトに問い合わせフォームなどはありません。メールです。
(今探してみたら 「https://www.witrigs.com/awrma/guest_rma/index Request RMA 」という返品/交換 希望フォームがありました。
公式サイトからどうやればここにたどり着けるのかは不明です。)
問い合わせメールアドレスは国別に用意されていて、日本語サイトにかかれているサポートメールアドレスには
日本語で書いても大丈夫です。

メールには以下の内容を書きます。

  1. 注文番号
  2. 発注者名
  3. 発注内容
  4. 症状
  5. 交換/返品 の希望
  6. Witrigsの箱の写真
  7. 不良商品の写真
  8. **** 動作不良証拠となる動画 ****

この「動作不良証拠動画」がなかなかに面倒です。
まず現代のスマートフォンなどで撮った場合、簡単に数百MBを超える動画となってしまいます。
そんなものメールで送れないので、圧縮するなり、クラウドサービスを使うなりして送る必要があります。

そうしてメールを送っても1週間は返事が来ません。
また、返事のメールも高確率で迷惑メールに分類されます。
今回私はgmailでやり取りしたのですが、
実は中国の検閲でGmailからのメールが届かない可能性があります。
私は届きましたが、返事が来るまで不安でした。
ですので、中国の検閲に引っかからないメールアドレスで購入し、その後のやり取りにつかったほうが良いと思います。

今回メールを出して1,2週間経っても返事がなかったので、英語サイトのサポートメールアドレスにもメールを出しました。
こちらは2,3日で返事が来ました。
しかし内容はさすが海外対応という感じで、内容はフランクで「もういっぺん試して動画送って」という内容でした。
「もう4回も試したんだが」と言っても聞く耳持ちません。
そうして英語サイトサポートメールアドレスとキレ気味にやり取りしていたところ、
日本語サイトサポートメールアドレスから返事がありました。
こちらとのやり取りはスムーズで、ことが滞りなく進みました。

このようなやり取りの後、Witrigsが不良品と認めた場合、
RMA Ticket」が発行され、そのメールが送られてきます。
メールに貼り付けられているURLに行くと、
自分の購入したものが何で、それが返品・交換どの状態にあるのかを確認できます。

このとき私は「返品」を希望していたのですが、「Status: 交換」になっていました。
もう返金してもらって、そのお金でifixitから書い直すつもりでした。
そこでサポートメールアドレスに問い合わせたら、
「もう発送しているので待ってくれ」
とのこと。どうやら金は返したくないらしい。
しょうがないので、もうお金は返ってこない、品物も来ないつもりで諦めました。

その後

上記のやり取りの1ヶ月後、なんと交換品が届きました。
動作チェックをするときちんと動くものが送られてきていました。
まあ、良しとしましょう。
無事パーツを交換し、私のPixel3は元通りきれいなものになりました。
おおよそかかった金額は、9,000円 でした。

交換品について

交換品の印刷をみると、初期に到着した不良品と同様に、LGの2018年製造品のようでした。
1つ異なる点が、「検品 2022.3」というスタンプが押されていました。
おそらく交換対応に合わせて検品し、発送したのでしょう。
初めからやれと。このへんが中国クオリティだなぁと。

まとめ

Witrigsは中国サービスの中ではまだましな方だと思います。
返品の手続きやら、反応の遅さやら、色々と不安はあります。
今回このような対応をやろうと思ったのは、Witrigs公式のコミュニティサイトの書き込みに
「不良品で問い合わせてもなんの返事もない、僕の金は消えてしまったよ」
と海外の人が書き込んでいたものに、
「すいません。対応します。注文番号を教えてください」
とWitrigsから返信がついていたことです。一応対応するつもりあるんだと。
ただまあ最初からちゃんとした製品を送れと。

こういったことのやり取りや、配送状況の追跡などが面倒なことになった理由の1つに、
私が購入時にアカウントを作成しなかったことがあります。
ですので、こういった場合ゲスト購入はしないほうがいいなと思いました。
合わせて、Googleなどの中国の検閲に引っかかるサービスを使用せず、
別のメールを使用したほうがいいなとも。

何はともあれ、完動品を入手することができました。
トータルで4ヶ月かかったりと大変ではありましたが、
業者に頼むと35,000円以上かかるところ、9,000円で修理することができました。

なにかの参考になれば。