Moonmile Solutions Blog

この日経新聞のポストに関して、脊髄反射的に「土管が賠償責任を負うなんて」という意見が付いてるが、考え直したほうがよいです。この問題は単なるインフラ＝土管として捉えているのではなくて、契約上「反社」としてわかっているところと契約をした上で、警告を無視して（米クラウドウェアじゃなくて日本営業所なのだろうけど）ずるずると契約し続けていた、というところが大きな問題です。

賠償金額は合計5億円（四社が各社1億2650万円）なので、ほぼ原告通りの金額が通ったと思われます。ただし、月間3億アクセスあることと海賊版の頒布という「幇助」が重なると、実際の被害額はさらに多かったはずですが、この場合「土管」のように見えるインフラ業者も敗訴する場合がある、というところが重要です。

今回の判決のその前に考慮する事柄

海賊版については、昨今の中国のあれこれも含めて、国内ならばなんとかなるものの国外に出てしまうと著作権の扱いが異なったりしてかなりややこしいです。このややこしいところを利用して「漫画村」のような海賊版配布サイトが発生したわけですが、その前提を踏まえておく必要があります。

• 「漫画村」のような直接的な海賊版配布サイトとその主催者
• 海賊版サイトの運営者と契約をしている、ホスティングサイト
• 海賊版サイトに接続する中間通信業者（プロキシサーバー）
• 海賊版サイトと契約する通信事業者

といういくつかのパターンがあります。このほかにも、海賊版サイトを裏で運営するための WEB サイトの請負業者や保守業者というものがあります。このあたりは、裁判沙汰にはなっていませんが、「反社条項」に照らし合わせると、芋づる式に警察に引っ張られる可能性があるので会社としては注意が必要です。

海賊版配布サイトとその主催者

まずは、海賊版配布サイトとその主催者は、あきらかに犯罪行為となるので、即捕まることになります。すでに刑事処罰を受けた人が出所しているぐらい時間が経っているので、犯罪であることはいまとなっては明らかなことです。ただし、判決として「懲役3年・罰金1,000万円」となるので、出版社等の想定被害総額（200億円程度と言われる）から見ると雀の涙ほどでしかありあません。これは民事訴訟で争うしかありません。

「漫画村」に関する損害賠償請求事件の判決言渡について | ニュースリリース | KADOKAWAグループ ポータルサイト https://group.kadokawa.co.jp/information/news_release/2024041801.html

これ、主催者に請求しても支払い能力がない（広告収入はあっただろうけど、果たしてそれが200億円に達するかわからない）ので、民事では 17 億円の賠償となっているようです。

ホスティングサイトの責任

現時点で「ホスティングサイト」の責任を問うときに、CDNのクラウドフレア社の件しかでてこないので、検証が難しいのですが、過去の例をみるとホスティングサイトにも責任があります。ホスティング会社の場合、コンテンツ業者との契約が発生しますがコンテンツの内容が問われることがあまりありませんでした。しかし、性的なコンテンツや反社的なコンテンツがあるとホスティング業者自体が廃業に追い込まれます。良い例としては FC2 があります。

企業コンプライアンスで次々と性的コンテンツ（静的ではないです）や違法動画を流すことをやめるホスティング業者が多くなっている中、 FC2 はそれらを野放しにしました。というか、経営的にコンテンツの内容を問わない、という形を貫きました。コンテンツの内容を問わないという点では「表現の自由」を支えることにはなるのでしょうが、違法コンテンツの配信をそのままにしておくという「犯罪幇助」に引っ掛かってしまいます。

FC2の法的責任：著作権侵害コンテンツを放置中！米国のDMCA（デジタルミレニアム著作権法）プラットフォーム責任の観点から整理｜アメリカ移民ケニー小倉の裏ログ https://note.com/onoshin_digital/n/n816a97c3e878

なので、単なる「場」としてのホスティング業者であっても違法コンテンツの配信を野放しにするわけにはいかないのです。

中間通信業者の例

違法コンテンツは電子的な配信がなされるため直接ユーザーと繋がっているわけではありません。途中に中間通信業者（プロキシサーバー等）を通ります。これは、順法コンテンツだとしてもかわりません。

このあたりを KADOKAWA が規制しようとした事実がありますが、その規制自体は違法です。

発端としたは「漫画村」のサイトに繋がる経路（IPアドレス、DNSサーバー）を制限しようとする法案を国会で通そうとましたが、失敗しています。いわゆる DNS によるブロッキングです。
しかし、これは「通信の秘匿」という意味で違法であり、却下されています。たしかに違法である漫画村サイトに対して DNS ブロッキングを行えば一般ユーザーからは接続はできなくなります。しかし、この DNS ブロッキングの方式は、先の順法サイトへのブロッキングも可能になるという法的な問題が発生してしまいます。
漫画村のような違法サイトであるということを誰が判断するのか？という問題です。　

DNS ブロッキングが通ってしまうと、ときの政府の思惑で「通信の秘匿」が侵される危険性が高いです。実際、中国では金盾でブロッキングされているわけですから、技術的には可能ですよね。抜け道としては VPN で抜けてしまっているのですから、これも違法サイトだけブロックするわけにはいかないことは明白です。

「漫画村」ブロッキング――誰が、どんな経緯で動いたのか – Yahoo!ニュース https://news.yahoo.co.jp/feature/1039/

というわけで、単なるデータを媒介する形での中間通信業者は、この件に関しては違法性はありません。逆に警察や政府が DNS ブロッキングを要請してきたとしても跳ねのけるだけの法的根拠があるというわけです。
まあ、実際のところはどうなのかわかりませんが。NTT が動いてしまった具合ですから。いわゆるときの忖度ですよね。

海賊版サイトと契約する通信事業者

いわゆる「土管」＝インフラ業者としてのクラウドフレア社のような場合はどうなるのか？というのが今回の判決です。まず、違法性の伝播としては、今回の反社と契約しているか否かにあります。当然のことながら契約書自体に反社条項が入っていれば、反社（この場合は漫画村の経営者）と契約を結ぶこと自体が違法です。
当初、クラウドフレア社は「違法な契約者かどうかがわからない」ことを主張してきましたが、これは出版社による再三の警告（あるいは通告？）により「違法性が高い」ことは認識されていたとみるでしょう。これを放置したことにより「犯罪の幇助」という判決に至ります。

だから、ある意味では契約時点ではわからないのは仕方がないです。実際に、契約した後に反社になるかもしれないので、契約時点あるいは契約後自体のそれは問われないはずです。しかし、契約している途中で客観的になんらかの形で反社としてわかった場合には、契約を見直すことをしなければいけません。これは、法的というよりも、今回の判決のように裁判に負けてしまうからです。会社として不味いですよね。

金額的にクラウドフレア社にとって5億円という金額は大したことはないでしょう。しかし、今後、コンテンツ業者が訴えた場合に、同じように敗訴になる可能性が高く、海賊版サイトとの契約の見直しが大量に発生する、というところがこの判決の影響になります。

さらなる波及として

おそらく、問題は Meta 等が広げてしまっている違法広告に訴訟が及ぶ可能性が高いです。Meta や Google は、違法広告をそのまま流しています。しかし、それは広告主の問題であって「土管」としての Meta や Google には責任がないという判断を各社がしていますが、これがひっくり返ります。反社であるとわかっていて契約をし続けた場合には、今回のクラウドフレア社のように敗訴する可能性が高くなります。ですから、Meta や Google は広告主と契約を結ぶ場合に、広告主が反社であるか否か、広告主が違法であることを警告された場合にそれに対処しなければいけないという義務（とリスク対処）が発生します。

実際のところ、ネット広告の出品は自動化されており、Meta や Google 自身がほとんど関与していません。「私は反社ではありません」のチェックボックスぐらいでしょう。逆に言えば、その関与していないことが今回の判決において問題になるわけで、次なるは違法広告の問題に発展するでしょうね。原告が誰になるかが微妙ではありますが、何かの集団訴訟にはなると思われます。

関連法案

この手の話は、電気通信事業法の第三号事業者とプロバイダ制限責任法の両方を把握しておきます。前者はホスティング等の通信事業者（仲介的に掲示板提供とかツイッターのようなミニブログとかも含まれる可能性あり）が守るべき義務と、後者は何か訴訟がおこったときに無限責任ではなく有限であるという意味で責任範囲を規定するものです。片方だけ知ってても片手落ちなので、両方知っておいてください。

電気通信事業法における第三号事業者とは？自社の分類を把握しよう! – オーリック・システムズ・ジャパン株式会社 https://www.auriq.co.jp/blog/kaiseidenki-daisango-category/

プロバイダ責任制限法とは｜削除請求・開示請求わかりやすく解説 | 誹謗中傷弁護士相談Cafe https://www.fuhyo-bengoshicafe.com/bengoshicafe-260.html

元ネタが消えてしまったので、ちょっとここに解説を書いておきます。

まず、ブリリアントジャーク（Brilliant Jerk）が「優秀だけれど協調性に欠け、組織に悪影響を及ぼす人物」という意味通りならば、できるだけ彼/彼女から避けてください、の一択です。Web で検索をすると「受け入れる」案がたくさんあるのですが、小規模のチームの問題ならばなおさらです。これは明確に “チーム殺し” via 「ピープルウェア」にあたるので、チーム自体が崩壊しかねません。なにがどのように優秀なのか？　目の前のチームが何を成し遂げようとしているのかをチームリーダーは見極めなければいけません。

元記事が大人の事情で消えてしまったので、状況だけを示しておきますが、

・アジャイル開発スクラムのメンバーである
・優秀なメンバーとして後から入ったが協調する気がまったくなかった

という場面です。そもそもアジャイル開発スクラムにおいてはチームメンバーの価値観の統一が最優先になります。これはスプリントと呼ばれる２週間の短期間のうちにプロジェクトの目標を次々と成し遂げないといけないために、まさしく “スクラム” を組み一丸となって進むことを示しています。たまにテック系の行動規範として「相手を尊重する」ことが入っているコミュニティを見かけますが、まさしくその通り、同じチームを組む以上チームメンバーを尊重することが必要です。これは、自分の意見を通すだけでなく相手の意見も聞くという意味も含めます。そのような意味でも、同じ価値観がなければ、チームで組むことはできないと他のメンバーも考えるし、スプリントの中で「徹夜」や「残業」などの嫌なことを乗り越えていくことができないでしょう。

そうなんです、アジャイル開発スクラムの場合は、メンバーの合意のもとでは「徹夜もします」ってのが条件だったりするんですよ、実は。

まあ、そんな訳でスクラムマスター（おそらくリーダー役？）が諭して直るパターンであれば、ブリリアントジャークというほどでもないし、ちょっとした勘違いテック野郎だったんじゃないですかね？　という具合です。

では、どう対処するのか？の具体例を示しておきます。IT 業界で「優秀だけど嫌な奴」の筆頭といえば、リーナス・トーバルズ氏です。口が悪くて相手への態度も悪い、容赦がないので有名ですね。でも優秀です。Linux を作った人ですし、現在も Linux を現役で支えている人です。最近の業界ではないのですが、IT の黎明期ではこのような天才的な才能があれば、なんとでも行ける部分があるので、結構こういう人が多いです。ちなみに私はリーナス氏が好きか嫌いかというと、いやどちらでもないです。どちらでもない理由は後述しますが、無責任な話でいえば、そういう人も必要ではあるだろうなぁという話です。これも無責任ですが、同じく後で理由を話します。

これ、IT 業界に限らずクラシックの指揮者とか、映画監督とか、アニメとか漫画家とかいますよね。ひとりの才能が拡散されている業界はこの手の「ジャーク（嫌な奴）」でもやってける部分があります。でも、やっていけるのはそれなりに理由（本人ではなく業界としての理由）があるわけで、ひとまず構造的にやれるようにメンバーを組むというのがひとつの方法です。漫才あたりとかテレビ業界もそうですが、「売れればよい」といのがそれです。そのあたりは市場原理もあるので、否定しません。

チーム内のジャークをどう扱うか？

アジャイル開発スクラムではない場合は、なんとかなります。そもそも優秀なのだから（何を以って優秀というのかは明確にしておいてください）、その「優秀さ」を最大限生かせるようにチームを組み直します。いえ、ある意味でチームを解体します。

先に言ったようにジャークは優秀であろうとチーム殺しの一つなので、チームに取り入れてはいけません。しかし、なんらかの事情でチームに取り込まないといけないという状況になったと仮定しましょう。実際、そういう場面はいくつかあります。

・プロジェクトが炎上してしまって、外部からジャークを呼ばないといけない。
・レガシー開発をしていたジャークしか直せないバグが発生した
・社内政治のナントカ（社長の息子とか取引先の縁故とか）でジャークが入ってきた

のような場合は、どうしてもジャーク君を排除できません。これはもう仕方がないです。諦めましょう。このジャーク君にどう対処して、できるだけ早くジャーク君がいらない状況を作ってしまうのが先決です。メンバーの方が大切です。ジャーク君を育てることを考えてはいけません。まあ、三番目の縁故の場合は、ジャーク君に取り入ることも可能なのですが、それは別の話です。

炎上プロジェクトの助っ人やレガシー開発での助っ人みたいなジャーク君に対しては、もうこれは仕方がないので、マネージャが接待してください。この一手で十分です。いわゆる、バスケでいうところのマンツーマンですね。

・ジャーク君が素早く開発できる環境を、ジャーク君専用で整える
・ジャーク君は、朝のミーティングとかチーム内ルールを免除する
・ジャーク君の暴言がチームメンバに向かったら、すかさずマネージャが割り込む

という具合で、本来のチームを持ってください。それがマネージャの役割です。そして、ジャーク君にはさっさと仕事を終えて貰って出て行ってもらいましょう。育てるとかルールを守って貰うとか何とか考えてはいけません。ジャーク君は別の世界の人ですから、私達には関係ないのです。ジャーク君が作る恩恵だけを享受しましょう。それ以外は不要です。対抗しようとしてはいけません。限りなく受け流してください。

社内のジャークをどう扱うか？

どちらかというと、こっちのほうが問題です。Netflix のカルチャーメモにあるように会社としても「ブリリアントジャーク」を排除してしまうのがベストなのでしょうが、まあ、そうはいっても入社してしまったし、というのが日本的な風土の問題ですね。また、リーナス氏のような優秀な（とも言えないけど）人材が会社に入ってきたらどうでしょう？　なかなか排除ってわけにもいかんでしょう、という心情はわかります。また、業界にもよっても違うわけで、クラシックの指揮者とか、アニメーションや映画の監督とか、舞台の役者とか、漫才師みたいなのは、真ん中のジャーク君を盛り立てて成り立っている業界的な構造もあるので外すことができません。つまり代替が効かないというパターンです。

ただし、このあたりの構造はダウンタウンの松本氏やフジテレビの問題やジャニーズの問題のように崩壊することが多いので、慎重に扱わねばなりません。ジャーク君は当然のことながら、素行が悪いだけでなく、法的なラインも自分中心に超えてくることが多いので、そのまま扱うと会社自体が崩壊しかねません。これは経営判断となるので取締役以上で決めることですね。一般的な会社員が決められることではありません。

それぞれの会社がどのようにジャーク君を扱うか、業界ごとに異なるでしょうから、ここでは IT 業界の会社の例に絞っておきましょう。

まず、小規模の会社（10人位とか）の場合は、もう駄目です。小規模の会社の場合は、社員＝チームメンバーという形になってしまうので、先のスクラムチームと同じ状態になってしまいます。この場合は、社長自らがジャーク君と対峙するしかありません。あるいは、ジャーク君担当の取締役を付けるしかありません。まあ、小規模 IT 会社の場合は、社長そのものがジャーク君の場合が多いので、その場合は社員が逃げてしまうので大丈夫です。よほどジャーク君が優秀でなければ生き残ることができません。他社と付き合わないといけないわけですから、疑似的であれ表面的な協調性は必要ですよね。芸能界でいえば、マネージャを間に挟むところですが、IT 業界の場合そういうものはありませんので潰れてしまいます。リーナス氏の場合は、かなり例外的です。

問題は100人程度の中規模な会社です。会社としてはジャーク君の配属を変えることができるし、ジャーク君の「優秀」という恩恵だけを会社が受け取れる状態になります。迷惑なのは社員のほうですが、これはうまく会社のほうで対処しなくてはいけません。そうしないと次々と退職者が出てきてしまいます。会社として、新人をひとり入れるのに年収の 1/3 程度がかかります。少なくとも一人の退職者が出ると百万円レベルの損失を考えないといけません。ジャーク君が配属された部署からひとり退職者が出るたびに、ジャーク君のボーナスから百万円を差し引いてもよいぐらいです。それぐらいのダメージを覚悟してください。

というわけで、中規模の会社の場合は、ジャーク君に権限を与えないようにします。先の火消しのようにジャーク君を使い潰してください。そのたびに、太鼓持ち風のマネージャを付けて申し送りをすればよいのです。ジャーク君が改心するかどうかはわかりません。

会社としては、ジャーク君の「優秀」な部分を取り出して、別の会社に売ればよいので、それだけで十分です。まあ、それでも Netflix のように排除するほうがいいと思いますけどね。

さて、いわゆる大手 SIer の場合はどうでしょうか？

実はジャーク君は組織の中に一定数、ちらほらと確率的に存在します。中学校のクラスの中でいじめが発生するのと同じぐらいの確率で存在しますね。いわば、組織が進化する上の必要悪…というより、ちょっとした不可欠な要素という面もあります。学校の中のいじめの問題は別な対応が必要なのですが（クラスメンバーが平等という前提があるので）、大手会社の場合は別な方法がとれます。なぜならば、大人数の組織の中では、それなりに上下関係ができてしまうものですし、会社組織としては給与体系とかあり上下があるのが普通だからです。学校の平等とは違います。

だからといって、大手組織の中でジャーク君を放っておくことはできません。先のフジテレビの問題のようになってしまいます。権限を与えてしまうと、権限が権限を呼び、先行き会社を傾きかねない事態に陥ってしまいます。フジテレビの場合は、ジャーク君自体が社長になってしまったので、時代性もあり仕方がないですね、ってのとどうしようもないね、ってのが私からの視点ですが、IT 業界でもたまにありますね。

唯一のうまい方法としては、ジャーク君たちをひとつの部署に集めることです。

実は大手の会社となると確率的に複数名のジャーク君がいます。ジャーク君は弱肉強食の中で弱者に対していじわるなだけなので、ジャーク君達、つまりは複数名をひとつにまとめてしまってください。いわゆる特殊部隊というやつです。ジャーク君自身には権限を与えてはいけないので、タフなマネージャーを据えてください。マネージャはジャーク君に同情はしません。操るだけです。

なんか見たことがあるでしょう？「攻殻機動隊」の公安８課とかパトレーバーの特車二課とかいくつか思い浮かぶはずです。公安８課の部長なんて、ちょうどいい感じでできていますよね。あれ、物語自体はフィクションではありますが、心理描写や組織体系は現実から逃れられないので（リアリティを出すために） “部長” の立ち位置と言動が本物に近いです。もっとも、政治に近いところであれができるかどうか不明ですが（おそらくできないような気がしますが）、理想像はアレには違いありません。

ジャーク君達は、研究職やら R&D やらで頑張って頂けばいいのです。彼らは優秀なので徹夜だとか勤務時間は全然気にしません。当然勤務態度も悪いのですが、そこは特別部署なので御咎めなしです。ただし、成果は出さないといけないので、弱肉強食ですよね。はたして、ジャーク君チームに入りたいかどうかは、一般的にはわかりません。

もちろん、研究職や R&D チームでも礼儀正しく協調的にやるほうがいいのですが、会社に入ってしまったジャーク君たちをどう扱うかという話になるので、こういうパターンもできます、ということです。

退職を促す方法については、閑職に移すとか色々あるので訴えられない方法を選んでください。これは実情がいろいろ世の中にころがっています。

もう 20 年以上前になりますが、マーチン・ファウラー氏が XP 関係で来日したことがあります。彼の講演でよく覚えているのが「私達の世代では、技術力を盾にしてひとりでやることが多かったが、これからチームでの社会性や協調性が必要になってくると思う」という話でした。アジャイル開発の黎明期でもあり、個人的な開発力よりもチーム力が重んじられてきた時期です。それ以前では、プログラマが知識と腕力で犯罪スレスレでもあってもいいから技術力を磨いてのし上がってきたわけですが（ファウラー氏もそうみたいだし）、これからはそうではないです、というのを彼の娘を例にして話していたのが印象的です。

別に仕事なのですから、学校のときのように仲良しこよしでやる必要はありません。時には給与査定もあるのですから、競争することもあるでしょう。しかし、いまどき敢えてジャークである必要はありません。プロジェクトという目的があれば協力し、プロジェクトがなくなれば特に協調しなくてもよいのです。仕事ですから。

そういう意味で、例えばリーナス氏のようなジャーク君が会社にいて、とある部署で業績を上げていたとして（それがジャーク君チームの R&D だとして）、それをどう思うかといえば、無関係ですよね、自分に被害が及ばない範囲であれば、と私は思う訳です。モノホンのリーナス氏はよく知らないので、なんとも言えないんですよね。なので、ここはリーナス氏風のジャーク君がいたとしての仮定のお話です。

もうこんな重たい IDE を使わくてもいいだろう、という形なのか、名前が「Visual Studio」に戻った Visual Studio 2026 がリリースされました。

Windows、Mac、Linux 用の Visual Studio と VS Code のダウンロード https://visualstudio.microsoft.com/ja/downloads/

インストールした後にスタート画面で「2026」で検索しても出て来ないので、おかしいなぁと思ったら「Visual Studio」になっているという具合ですね。私の PC では互換用に 2019 と 2022 がインストールされているのですが、今回の 2026 は間に挟まっています。ちょっと見つけ辛い。

ちなみに、起動時にスプラッシュ画面やヘルプメニューからの「Visual Studio の登録」を見ると、きちんと “2026” の文字が入っているので区別が付きます。

たぶん、従来の Windows フォームとか ASP.NET Core MVC アプリとかを作っている間は以前と変わらないと思います。.NET が 10.0 なので昔のプロジェクトを開くときは、*.csproj を開いて変えてしまえばよいでしょう。

特筆すべきは、Visual Basic で iOS アプリが作れる（らしい）ことですね。本当に作れるのか不安なのですが、.MAUI ベースじゃなくて、Objective-C ベースを VB に直したコードをがテンプレートになっています。

なんなのですか！この魔改造っぽいプロジェクトはｗ

逆引きシリーズとの比較

ざっとですが、逆引きの C# 2022 のプロジェクトが Visual Studio 2026 で動作するか確認してみました。

『現場ですぐに使える！ Visual C# 2022逆引き大全 500の極意』https://github.com/moonmile/gyakubiki-vcs2022

第1章から第17章までを開いてみる限り、ターゲットフレームワークを「.NET 6.0」から「.NET 10.0」に変更すれば ok です。サンプルコードでは、src 配下に global.json で .NET 6.0 固定にしてあるので、このファイルを削除してください。

第16章 モバイル環境の極意は古い MAUI を使っているので動かない可能性が大です。
第11章 データベース操作の極意 と 第17章 Excelの極意 は、ひとまず NuGet でライブラリを最新にしてください。多分、互換があって動くとは思うのですが、DB のほうはちょっと未検証です。

逆引きシリーズをどうしたものかと思っているのですが、実は 2022 のときにもうこれが最後だろうと思っていたので結構無茶な形で組み込んでいます。VB のほうは、自前のテンプレートを作ったりして無理矢理 C# に合わせたり、ライブラリ化して Android で動かしたりという感じです。
いや、さすがにひとりで1000ページは辛いので、これが最後という感じだった訳ですが。

その後、秀和システムが無くなって、シン・秀和システム…じゃなくて秀和システム新社になったわけですが、逆引きシリーズはどうるのだろう？と思っているのですが、今サイトを見ると ACCESS とかの逆引きが出ているので、続いてはいる模様です。

となると、ここは是非「Visual Basic で作る iOS アプリ」という誰に需要があるかわからない章を追加しないといけないわけで（Visual Basic の逆引きには先に書いた通り、無理矢理 .NET MAUI の章があります）、これを試さねばなりません。というわけで、ひと通り見たら、連絡を出しましょうか。
中味的には AI エージェントを入れてコードを追加して 2022 よりも盛ることは可能なんですよね。ページ数的にはもう一杯一杯だと思うので、ページに合わせて詰め込んでしまうか、コードを少し端折りめにするか。逆引きのコードは基本全文が載っているので、そのあたりは要相談で。

追記

確かに、VB のコードが iOS 上で動いています。SwiftUI は動かないようなので、従来型の storyboard 形式で書かないといけないのでなかなか敷居が高いですね。storyboard 形式は Xcode で作成するか、最近だと Copilot の Agent モードを使っても書いてくれます。
なかみはほぼ Objective-C のコードの引き写しになるので、従来の C# + Xamarin コードを知っている人ならば勘でなんとかなるだろう、とは思うのですが…これって、誰得なのか？　そもそも、これを開発した Microsoft 社員は誰なのか？　が非常に興味があるとこです。

ちなみに、ASP.NET Core MVC の VB テンプレートは入っていないので、これは自分で作らないといけません。むしろ、こっちのほうを MS さんは作って欲しかった ！！！

微妙にネタツイっぽい気がするのだが、レスのほうに「人格まで否定されたと感じる経験」がよくわからないという意見が多かったので、その部分だけ補足しておきます。

Z世代つまり2000年以降に生まれた世代が 25 歳になったわけで、ぼちぼちと就職してきます。大卒であれば 22 歳ぐらなので、ここ3年位から続いている訳です。なにも2000年からいきなり人類が切り替わったわけではないので幅があります。教育課程でいえば実はZ世代は、いわゆる「ゆとり世代」の後にくる世代になります。当時ゆとり教育が問題になって、円周率は3で計算するというのが話題になりました。小中学校での授業時間も減り、大学入学時までに習得する学習過程も大幅に減ってきたところです。しかし、学力低下がみられるところから一変して「ゆとり教育」を廃止して、授業数が多くなったのが Z 世代です。最近では土曜授業も月に1,2回行われるようになって、授業数は増えています。平日の授業も6,7 時間と増えているところもあります。

この平日の授業時間の増加は、昭和の世代からみても多いものです。これはゆとり教育の反省というよりも、現在義務教育で教えなければいけない要素が多くなってしまったということでしょう。様々な道徳教育や情報、理科にしても社会にしても以前よりも数多くの事実が体系化されるようになりました。中学校の教科書もページ数が多く、さらに副読本もついているので実に大変です。詰め込み部分も多くみられます。

そんななかで、大学の一芸入試や OA 入試とよばれる推薦入試が一般化してきました。これは高校入試でも同じで、中学のときの内申書（いわゆる五段階評価）に加えて技術家庭などの副教科を加えた内申の点数で推薦先を決めることが多いです。昭和世代だと、推薦入試なんてそう多くない人数だったと思うのですが（これは、出身中学や高校によるのでしょうが）、いまの中学校では、1/3 程度が推薦入試を受けます。つまり、試験一発で受かる一般入試は 2/3 程度の中学生しかいないということです。
推薦入試は、高校からすれば、素行の悪い学生を排除することができる良い制度ではありますが、推薦する人数が 1/3 ともなると、学力もたいしたことがないことが伺えます。平均よりもちょっと上程度の位なのですから、昭和世代のクラスで1人か2人程度の推薦枠どころではありません。

そうなると、先の内申書が問題になってきます。
本来ならば、内申書というのはある程度クリアできていればよいもの（極端に成績が悪い人を落とす）程度のものだったはずが、推薦入試（東京都では併願確約というのもあります）を通すために、普段の授業の点数を上げることに必死になってしまうのです。ただし、必死になるのは生徒ではなくて、教師側のほうです。
教師が生徒たちの内申をつけるために、授業の手を上げる回数だとか、グループ発表の点数だとか、遅刻の数だとか、クラブ活動の態度だとか、諸々の基準で数値化していきます。この評価が実に大変で、授業ごとに生徒が手をあげた回数＆発表した回数を数えないといけないし、答える人も順番にあてないといけません（平均的に当てないと、親からクレームが来ます）。昭和の頃にも、教師が「内申をさげるぞ」と脅すことがたびたびあったのですが、それは推薦の子に限って。一般入試の子にはさほど響きません。しかし、現状のように 1/3 もの推薦（落ちる子も含めれば 1/2 に近い形で推薦入試を受けます）枠になってしまうと、「内申が落ちる」という脅しはかなりの人数で効いてきてしまうのです。

小学校のころに運動会で平等にとか学級会の話し合いでとかいう次の中学校でこんな具合なわけですから、それぞれの「人格」がどうというものは消え去ってしまいます。
もちろん、建前上、「個性」を重んじるようには見えますが、結局のところ推薦入試のために偏った細かすぎる評価基準のためにそれぞれの「個性」は見えない状態になり形骸化してしまいます。
それもあって、不登校の子も多いのです。クラスに1,2人は必ずいるという状態です。

そのような意味で「人格まで否定されて」という雰囲気が中学生時代にあり、それを経て高校・大学その後に就職というのが現在の Z 世代の現状です。否定されるというか、無視されてというか実に「個性」と「評価基準」との間を行き来しながら今に至っていると考えられます。
なので、最近の Z 世代は相手に対して実にきれいな敬語をつかいます。これは上司とかではなく、同期であっても敬語を使うし、最初からフレンドリーということはありません。勿論、新人教育の中で少しずつ慣れてくるのですが、そのあたりの「きれいな敬語」（私からみると場をわきまえない、TPOにそぐわない変な敬語）を使うのは Z 世代特有の、相手を傷つけない争いを起こさない、という下地あるいは防御本能から来るものと考えられます。

で、元ネタの「構造～」なんとかはさておき（ネタっぽいし）、この場合「遅刻前には連絡してね」で十分です。Z 世代は先に話したようにルールに厳格な人が多いので（まあ、その後の高校によったり、性格によるものがあるでしょうが）、IT に限って言えば、生真面目過ぎるのが難点なぐらいです。

サイトを見るとわかりますが、アフリサイトなので御察しですね。

某所で失敗したのは3日間ほどなのですが、これ意外と知られていないので流しておきます。
以前、会社にいたころに XML-DB を扱う自社製品があって、それにアクセスする I/F を作っていました。外部的には Java ライブラリを使ってアクセスするのですが、ちょっと事情があって内部的にアクセスするライブラリを C/C++ で開発することになったのです。

で、その XML-DB がですね、実は Delphi で作られていたのです!!!
いまだと Delphi という名はあまり知られていないものの 30 年近く前には、意外とメジャーな言語でした。ググると分かるのですが、Delphi のベースは Pascal です。もともと Pascal は教育言語として開発されたものなのですが、それを実用化したのが Delphi というわけです（当時は Borland 社が開発・販売していて、名前は違うのですが、ここでは Delphi に統一しておきます）。

今だと何故に Pascal 言語が？　と思うかもしれませんが、まだ Java も広がっていなくて C# も出ていない時代です。Windows アプリケーションを組むとなると VC++ でがりがり組むか、Visual Basic 6.0 で GUI を組むかという時代です。
当時、クラスライブラリが乏しくて、C++ だと XML をパースするのに Xerces などの外部ライブラリを使う必要がありました。で、VB6.0 の場合は GUI は簡単に組めるのですが、この手のロジックあたりが弱くて、そういう場合は仕方がなく VC++ で組むことになります。
まあ、当時の VC++ は GUI の開発環境が貧弱で MFC のライブラリ以前だったり、その後に出てきた MFC も使いづらかったりしたのですが、そこで登場したのが Delphi だったのです。VCL と言う GUI ライブラリがあってですね、それが広く使われていたのです。
で、今で言えば科学計算を学ぶには Python が一番!!! というように、Windows アプリケーションを組むならば Delphi!!! という時代があったわけです。皆さん、わざわざ Pascal 言語を学んでいたのですね。すごい。

そういう経緯があって、ちょっと先進的な GUI だったり、ちょっと気の利いたライブラリだったりは Delphi で作られていることが多かった時代があるので、ちょっと優秀なプログラマが XML-DB を組むときに Delphi で組むのも不思議ではなかった時代があったのです。

で、悲劇はその後に起こります。

その後 Microsoft が VC++ を改良して、MFC というクラスライブラリを充実させていきました。先に書いた Xerces などのライブラリも C/C++ から使えるようになってきました。MFC のボリュームが VCL に近づき、会社の規模から見て VCL を凌駕していったわけです。

そうなると、開発者のボリュームとして、Delphi を使う人が減少してきました。VC++ の GUI 環境が整うにつれて、VB6.0 からも VC++ に流れて来たのです。最終的には C# や VB.NET に移っていくわけですが、その間に VC++ で書かれた Windows アプリケーションのコードがたくさんあります。

その時点で起こる現象として、Delphi で作られた XML-DB のライブラリを C/C++ で呼び出すことになります。つまり、遺産をうまく使っていこうという発想です。

そんな状況で Pascal を知らない C/C++ プログラマ（つまり私）が移植担当になって、調べていくとですね、あれ？　文字列の呼び出しが変？　ということになります。

ご存じの通り、C/C++ の文字列の終端は NULL 文字（’\0’）になっています。

C 言語

char str[] = "Hello";

この場合、str は ‘H’, ‘e’, ‘l’, ‘l’, ‘o’, ‘\0’ という文字列になります。

ってな具合に Copilot に書いてもらうくらい簡単なものです。
じゃあ、Delphi の場合は？　というと、Delphi の文字列は長さ情報を持っているのです。つまり、文字列の先頭に長さ情報が入っているわけです。

Pascal

var str: string;
str := 'Hello';

この場合、str は長さ 5 の情報と ‘H’, ‘e’, ‘l’, ‘l’, ‘o’ という文字列になります。

Pascal の場合には、NULL 終端ではなくて、長さ情報が先頭に入っているわけですね。

C 言語的に言えば

• str[0] が文字列の先頭
• str[-4] が文字列の長さ（4 バイト整数）

ってわけですよ。

えええ！！！　配列をマイナスにしていいのかい？？？

ってくらいです。C/C++ プログラマにとっては。

文字列よりも前に何かメモリが必要ってのは不思議でもありますが、ASN.1 の規約を知っていれば不思議じゃないもので（これもググってください）、規約として先頭に文字列の長さを入れることがあります。

Java や C# だと string クラスを使うのが普通ですが、C/C++ や Pascal だと文字列は配列なので、こういうことが起こるわけです。まあ、正確に言えば、配列に埋めているだけなので、ASCII なのか、Unicode なのか、UTF-8 なのか、UTF-16 なのかで終端も変わってくるんですけどね。特に Unicode の場合には wchar_t 型を使うので、2 バイトの NULL 終端になります。これも 1 バイト終端と間違えてバグる可能性大です。

C/C++ と Delphi の文字列の扱いや配列の扱いが異なるので、これを相互変換しなければなりません。さらに、この手の情報をファイルに落としたり、メモリで一括で扱うときには、NULL 終端の場合は 1 バイトなんですが、長さ情報は 4 バイト使っている !!! ってことになり、バイナリデータの扱いも変わってしまうのです。

Delphi でバイナリデータを作って C 言語で読む場合にはちょっと面倒なことになります。
配列とかすべて再定義しないといけないですからね、もう大変ですよ。

そんなわけで、当時はまだ Delphi の名残が残っていたので、まあなんとか文字列終端の違いに気が付いたものですが、さらに 30 年程経ってしまうとですね。

化石的な Delphi ライブラリが残っていて、これに遭遇するわけです。
Java でアクセスするとか、C# でアクセスするとかの問題ではありません。

なにこれ、変？　なんなのこれ？？？

と3日間ほど悩んでも仕方がないところです。

と、まあ、このあたりは私の想像なので、実際のところはよくわかりませんが、そのあたりが垣間見れてしまったので、ちょっと面白かったです、って話です。自分のことだときついのですが、所詮、他人事ですから。ははははははは、はぁ、お疲れ様です。

最初に断っておくと、この手の生成 AI による小説書きについては是でも否でもありません。先の小説の解説を見れば AI で書いてあることは明白であるし、その戦略を明示されていて、アンフェアな感じはしません。YouTube で F5 キーを押して回転数を稼いでいるわけでもないし、偽装メールアドレスを使って ☆ を使って稼いでるわけでもなさそうなので、これはこれでよいのでしょう。

実際「数で稼ぐための創作論」という形で、カクヨムの数（多分、ランキングに上がるための☆の数）を稼ぐための手法としては、非常に有効な手段であると思います。

ただし、数を稼いだからと言って、商業デビューできるとは限らないのですが、ここでは☆の数だけに注目してみます。

ハーレクインロマンスというジャンル

AI に小説を書かせるときには、登場人物やある舞台背景を設定します。当該の異世界転生の令嬢という話であるならば、そこそこの設定を書けば十分です。できるだけ、現在の流行りの設定を書くのがよいでしょう。

昔（いまでもですが）、ハーレクインロマンスというジャンルがありました。ハーレクインロマンスは、アメリカのロマンス小説の一ジャンルで、女性向けに書かれた恋愛小説です。特徴としては、裕福で魅力的な男性と普通の女性が出会い、恋愛関係に発展するというストーリーが多いことです。登場人物は典型的なキャラクターであり、男性は強くて保護者的であり、女性は魅力的で感情豊かです。物語はしばしばドラマチックで、感情的な葛藤や障害を乗り越えることがテーマとなっています…という筋書きがあらかじめ決まっています。この解説文も Copilot の拾ってきたもので、Copilot 自身もよくハーレクインロマンスの構造がわかっています。

ハーレクインでは、導入部分がどうなるのか、展開がどうなるのかというページ数がほぼ決まっています。当時は、AI というモノがなかったので、ゴーストライターがたくさん集まって、次々と似たような小説を出しています。いわゆる、昼メロのドラマの視聴者をターゲットにしたアメリカの小説ですね。もう、40年程前からあるものなので、家庭の主婦を対象にしています。そして、毎回同じメロドラマが繰り返されるのです。

これ、面白いかと言うと、まあ、1冊だとそこそこ読めるようにできているのですが、5冊ほど買って読んでみてください。できれば、同時並行で読むのがお勧めです。同時並行で読むと、登場人物たちが、どのように恋愛をして、どの部分で何かの事件に巻き込まれるのか（ちょっと覚えていないので、事件があったかどうか定かではないのですが）、どのように解決してロマンスに陥っていくのかが、ページ数で決まっているのです。だから、どんな小説家、というかライターが書いても似たような小説ができます。構成にあわせた、量産品小説ができるのです。

この作戦は、なにもハーレクインに限ったものではありません。雑誌のゼクシィやバイク雑誌、フランス書房なども似た感じで作っています。私が好きだったのは 30 年前のティーンエイジャー小説なのですが、これは学園もので、ちょうど現在の異世界転生の学園ものに近い感じです。アメリカ高校生のダンスパーティのシーンがあったり、生徒会が出てきたりします。これも定番で、どの本を読んでも似たようにダンスパーティと生徒会が出てきます。まあ、3,4冊で飽きてしまうのですが、暇つぶしにはいいです。たしか、ハヤカワ文庫であったはずなのですが、今は見当たりません。これは、当時、各出版社が作っていて、結構シリーズ化されたんですよね。漫画でいえば渡辺多恵子の「ファミリー!」が近いです。「ファミリー!」自体は量産品ではないのですが、このようなスクール生活中心の物語が、ハーレクインのように繰り返し出版されていました。たしか、中高生が漫画しか読まなくなって、小説が激減した時期で、それを盛り返そうとしてアメリカの青春小説を輸入しはじめたのが発端だと思うのですが、まあ、すぐに廃れました。SF が売れない時期で、ハヤカワもこんなのに手を出したのか、と思った次第です。まあ、その後 SF が復興したんですけどね。

そういう意味では、異世界転生のラノベブームも似たようなものですが、異世界転生の場合は設定が多様化していることと、意図的に似せてはこなかった、むしろ設定を変えて差別化してきたところに特徴があります。

量産するという占い方式

ところがですね、「数で稼ぐ～」の展開としては、これを意図的に逆にしています。

つまりは、ハーレクイーンの時代に戻して、構成を同じにしたわけですね。

さらに、カクヨムの特性として、新作リストがトップページ等に出ることを使って、似たような設定でたくさんの連載小説を AI で作るようにしました。つまり、量産したうちの 1 本が当たればよいというスタイルです。これは「占い方式」で、相談者に適当に YES/NO で答えて、YES で当たっていた方だけを残していく方式です。たくさんの同型の小説をアップしておいて、当たりだけを残せばいいのです。Web テストの A/B テストみたいな感じです。

作者のページを見ると同時並行的に10本以上の連載小説が並んでいます。どうやら、日に38本位を同時にアップしているそうなので、新作のリストが埋まってしまうという苦情も寄せられています。

人が書いた場合にはさすがに 38 本も同時には書けないのですが、生成 AI では難しくはありません。ただし、人が内容を確認するとスピードが遅くなってしまうので、内容はほぼ確認していないと思われます。

そんな中で今回は、そのうちの1本がヒットして、総合ランキングの1位になったわけです。おそらく、たびたびジャンル別のランクには上がっていたと思うのですが（過去の☆を見ると、取れそうな感じはするので）、今回話題になったのは「総合1位」という話題性でしょう。

自動生成されているので、小説の中身は問いません。

ただし、小説を読んで☆を付けている人がいるわけで、それが人の書いた小説よりもランクが上になったという事実がここにあります。

まあ、作戦的には「AI で量産する」という人間業では無理ということをやっているので、多少反則な気もしますが、それは、将棋 AI が人間に勝った、みたいなものです。まあ、読者は人間なので、判断的にも人間が凌駕したともいえます。

自動生成の実践

仕掛けがわかったところで、実践をしてみましょう。

私自身は、AI による自動小説はあまり興味がないのですが、実験的にやります。以前、まだ ChatGPT 4 あたりが出たばっかりのころに設定を使って書いてみたのですが、あまり面白いものはできませんでした。最近では、結構、キャラ付けをすると面白いことができます。

文体に関しては、例えば「村上春樹風に」とか「星新一風に」とか「夏目漱石風に」とか結構できます。今回は「庄司薫風に」してみましょう。庄司薫は「あかずきんちゃん気を付けて」などを書いた芥川賞作家です。青春小説の走りみたいな形で、薫くんシリーズは 4 冊しか出ていないのですが、当時はエポックメイキング的なところがあって、誰もが教科書的に読んだものです。

時代は大学の学生運動の頃なのですが、皆が血気さかんな時期に自制して思考することを優先した青年の話ですね。いわゆる、学生運動や当時の社会思想的な小説家たちが「行動すること」を中心とした時代へのアンチテーゼみたいなものです。

手順としては、以下のように作っています。構成については、あえて、総合1位のものをパクってきています。これは、どの小説でも構いません。

1. 曲がり角でぶつかった少女に回復魔法を使ったら不治の病と盲目なのを治してしまってめちゃくちゃ懐かれてた（夏見ナイ） – カクヨム https://kakuyomu.jp/works/822139837599758883 から、全話を抜き出します。
2. NotebookLM に突っ込んで、マインドマップを作ります。
3. 登場人物のリストを抜き出します。
4. 設定や舞台背景を抜き出します。
5. 大まかな事件を抜き出します。
6. これらを元にして、SF 風に ChatGPT に仕立てて貰います。
7. 生成された文章を、さらに ChatGPT に庄司薫風に直して貰います。

※ 登場人物の名前は著者に敬意を示すために、そのまま残してあります。
※ AI 生成そのままなので、著作権はないんですけどね。すこし手直しすると、著作権が発生します。

できあがった、小説と途中の markdown ファイルは、NotebookLM https://notebooklm.google.com/notebook/9508ee51-4a21-42d4-bf6c-856cfc9274aa に共有しておきます。

ハーレクイーンのようにバリエーションを付ける場合は、SF的展開.md のように、古代風とか中世風とかで作ってください。事件もろもろは、適当に追加すれば ChatGPT が整合性をあわせてくれます。おすすめはしませんが「数で稼ぐ～」のようにカクヨムにアップしてもいいのですが、これは自己責任でお願いします。

これ、実験的には面白い試みではあるのですが、小説的に面白いかどうかは別ですね。

さらに、商業的にデビューを目指すのであれば、全面的な AI 生成はやめておいたほうがいいと思います。文章力がつかないし、構成力も借り物にしかならないので結果的に面倒くさいです。ただし、将棋 AI のように、論理的に突き進む場合（誤字がないとか、構成的な矛盾が出ないとか）は、AI のほうが向いています。私としては、AI とのペアプロというかペアで執筆がお勧めです。誤字とか構成チェックに AI を使うとか、ところどころの定型文で AI に書いて貰うとかしたらよいでしょう。

余談ですが、LLM のモデルとしてカクヨムの 100 万本の小説が抜き出されて、それを活用して、という噂話があるんですが、これは本当かどうかはわかりません。

そのモデルを使えば、確かにカクヨム読者に特化した文体と中身が出来そうな気もするのですが、先に書いたように「量産して1本だけ当たった」状態なので、あまり意味がないです。この場合、量産して全てを当てるか、1本だけ書いて1本当てる、パターンで使うのが正しいので、今回のように10本以上の連載のうちに 1本だけ当たったというのは、確率的に質が悪いです。

それに以下の ChatGPT に書いて貰ったものを見ると分かるのですが、いまの GPT5 だと、結構書けるんですよね。こうなると、わざわざカクヨムの小説を学習させる必要もないような気がします。

以下は、自動作成した小説の第1章をサンプル的に

第1章 転移とユウキの静かな願い

帝都の夜って、星が負けるんだよな（いい勝負する日もあるけど）。二つの衛星が雲の切れ目からのぞいて、軌道リングを牛乳みたいに縁取っている。俺は六畳ちょいのモジュールで、ぬるい合成コーヒーをすすっていた。重力は薄い、眠気は濃い、みたいな感じで。

俺――ユウキ・アスカワ。前世は日本の社畜で、定時は神話、終電は日常、っていう生活。で、ある晩に限って紙を拾おうと屈んだら視界が暗転した。ありがちな黒い画面のあと、あんまりありがたくない白い部屋。青白いイケメンがポテチ食べながら言うわけだ。「願いは？」って（そんな軽いテンションで訊く？）。

「穏やかに暮らしたい」。はい、反射で出た。戦わない、目立たない、誰にも使われない。要するに、静かで、勝手で、ちょっと疲れてる人の願い。彼は肩をすくめて、電子ノイズっぽい声で「加護を授与。生体ナノ群体、管理権限付与。君の手は癒やしの光になる」とか言う。いや、それ、穏やか要素どこ。

目を開けたら天井は白くなくて、金属と消毒薬の匂いがした。帝都軌道ハビタットの医療区画。手のひらに意識を寄せると、そこに“ざわめき”がある。見えない粒が、命令待ちの兵隊みたいに。恐る恐る擦り傷に触れると、金の粉塵みたいに光って、熱で皮膚が縫われた。

「……派手すぎ」

安堵より先に、それ。黄金って、とにかく目立つ。目立つって、つまり危険（この帝国では特に）。生体ナノ群体は軍事と政治のど真ん中に置かれる技術だし、俺が誰かの“所有物”になる可能性なんか想像しただけで、前世の偏頭痛が後頭部でうずく。

だから、決めた。——誰も見てないところでしか使わない。小さな傷だけ。血も涙も避ける。黄金は俺のためだけ。以上。

退院して渡されたのは、身分コード、住所モジュール、星港補給デッキの軽作業の紹介。帝国は新参者をいきなり実験台にしない（少なくとも表向きは）。俺は無表情の練習をして、荷役に混じった。

補給デッキは帝都の胃袋だ。肉、穀物、機械部品、誰かの手紙。コンテナはどれも金属の匂いがして、フォークリフトのホイールとマニピュレータの油が静かに歌う。遠心重力のわずかな傾きが足裏を撫で、時々、貴族仕様の白いコートが視界を横切る（襟の紋章で家柄が読めるの、何回見ても慣れない）。

俺は端っこで暮らす方法を覚えた。朝はドックの冷気、昼は肉屋の親父の端肉、夜は薄重力の部屋で旧地球の音楽を小さく。

「兄ちゃん、また端っこでいいのかい」

肉屋の親父は、俺の好み（脂多め）を勝手に覚えるタイプ。太い腕、笑うと目尻が消える。店はプロムナード寄りで、貴族も庶民も肉の前では平等に真剣だ。

「端っこが一番うまいんですよ」

「そういうの、わかる口だ」

冗談を返せるくらいには、暮らしが体に馴染んできた。手のひらの群体は賢くて、命令の粒度を落とせば光は抑えられる。小さな裂傷なら、皮膚の色がほんの少し温むくらい。誰も気づかない。俺は“傷を作らない”歩き方も練習した（これが意外と難しい）。

……でも、目を逸らせない時ってある。夕方、補給デッキの影で小さく泣く声。膝を破いた少年。血が透明フィルムに貼りついて、見てるだけで痛い。

「大丈夫か」

しゃがんで、手のひらをかざす。閾値は最低。発光はゼロ寄り。空気がほんの少し金色に濁って、痛みがほどける。

「……あれ、痛くない」

「気のせい。よくある」

立ち上がると、少年の目が一瞬だけ大きくなって、すぐ普通に戻る。礼を言って走っていく背中を見送りながら、俺は手を見る。光はない。昼夜サイクルは、少しだけ夕方へ傾いた。

目立たない。目立たない。目立たない。これは呪文。前世で生き延びた術が、今世でも通用するかのテスト（合格してほしい）。

ハビタットは巨大な円環都市で、内側に人工の空と木々、外側に星と軍艦。帰り道はいつも同じ。正面エスカレータは使わない。螺旋のメンテ階段、広告が少ない側道。世界から半歩浮いて歩くと、なぜか安心する。

その頃から、星港の“噂”が耳に入ってきた。近衛艦隊司令の一人娘――シルフィード公爵家の令嬢が、長らく神経インターフェース不全で視覚補助が効かない、とか。帝都医療局総出でも原因不明、とか。噂ってのは、たいてい最初の一文で充分。残りは聞かない（関わる未来、想像したくない）。

続きに興味があれば https://notebooklm.google.com/notebook/9508ee51-4a21-42d4-bf6c-856cfc9274aa を見てください。

補足 2025/11/01

AI 作家による大量投稿によって、新着リストが埋まるのでは？　という懸念が X に上がっていますが、実際にはそんなことにはならないです。例えば、以下はカクヨムの「異世界ファンタジー」の新着リストになります。
このリストの新着時刻を見ると、

• 2025年11月1日 11:22
• 2025年11月1日 11:16
• 2025年11月1日 11:14
• 2025年11月1日 11:11
• 2025年11月1日 11:11

のように、10分間以内にも数件上がってくる様子で、1時間もあれば新着リストが一巡してしまう勢いです。しかも筆者は別々になった状態です。

つまりは、既にカクヨムの新着投稿では1時間で一巡するぐらいの流量があるので、AI 作家がちょっとやそっと入れたところで新着投稿のリストを埋めることはできません。もし、AI 作家が 1時間に1回以上の投稿をすればリストに載る程度のもので、埋めようと思うならば、1時間に40本位は上げないとリストは埋まらないでしょう。つまり、実質としてはひとりの AI 作家がリストを埋めるのは無理です。
もちろん、AI 作家が 10 人位でてきて、同じように 1 時間に 2,3 本ペースで up していったとしたら、新着リストは「複数の AI 作家」によって埋まってしまうかもしれませんが、それは、そのときになったときに判断すれば良いでしょう。少なくとも、運営側が判断する話です。現在のところ、傾向としては 1 人の AI 作家なので問題は少ない。しかも AI 作家だとしても、1 時間に 1 回程度の投稿であれば（24時間であれば 1 日 24 本まで投稿が可能です）、特に新着リストを荒らすことはありません。十分、許容できる範囲と思われます。

もちろん、それは実際に作家になりたい投稿者と☆の数だけが欲しい投稿者との混在になってしまうのですが、現状でも似たような感じなので、そこは AI 作家の問題とは異なるものです。

まあ、個人的に言えば、「あ、これ面白い」と思ったものが AI で書かれていたものだとしたら、ちょっと鼻白みますね。AI を活用して書いたのならばいいけど、全面的に AI に頼っているものを読むのは騙された感じがするので、二度と読まないと思います。

追記 2025/11/14

カクヨムから声明がでました。生成 AI に対してという訳ではないですが、過度な頻度での投稿の禁止です。

過度な頻度で作品やエピソードを投稿する行為はお控えください – カクヨムからのお知らせ https://kakuyomu.jp/info/entry/2025/11/13/170248

AI からの自動生成は禁止しないけど、あまり極端なのはやめてね、という具合ですね。当該のアカウントは BAN されていはないので、OK なようです。毎日更新は続けているので、それはそれで良いのかなぁと。

定期的に OneDrive dis が発生する X 界隈ではありますが、まあ、確かに「OneDrive の同期」については最初は切っておく、ってのがベターです。というのも Dropbox のようにバックアップ環境としてファイルを置いておく感覚で OneDrive にファイルを置くと痛い目にあいます。

Dropbox ではファイルのバックアップなのでクラウド環境にファイルを退避すれば、ローカル PC にあるファイルを消しても構いません。ファイルはクラウド上に残ります。これは感覚的にあっています。倉庫に物を置くようなイメージですからね。

しかし、OneDrive の場合は同じことをやるとクラウド上のファイルも消えてしまいます。一般的なバックアップシステムのような振りをしていますが、実は「複数の PC で同期」するのが主目的なので、削除した場合はバックアップ…じゃなくてクラウド上のファイルも消えてしまいます。さらに言えば、同じアカウントで入っている別の PC からも消え去ってしまいます。これは一大事。ってのが、何度も繰り返される OneDrive dis の本質でしょう。

OneDrive はクラウドのバックアップじゃなくて、同期システムなんだ、と何度言っても無理なので、ここは潔く「OneDriveを使用しない」あるいは「部分的にしか使用しない」に留めておきます。ちなみに、私は「部分的にしか使用しない」ことにしています。

OneDrive を使わないようにする。

いったん、OneDrive を使わずに同期をしないようにしてしまいます。おそらく Windows 11 をいれるときに Microsoft アカウントを入れるのが通常なので、ほぼ無条件で OneDrive でリンクされてしまいます。PC が 1台だったらいいのですが、複数台（ノート PC と在宅 PC とか）を使う場合には、いったん OneDrive を1台だけに絞って、他の PC では使わないようにしたほうが間違いが少ないです。

Windows 11 のタスクバーから、クラウドアイコンを右クリック

歯車の設定アイコンをクリック

メニューから「設定」を選択

OneDrive 設定から「アカウント」を選択して、「この PC からリンクを削除する」を選びます。

たとえば、持ち運びをするノート PC とか、一時的に Windows アカウントが必要だったときの業務 PC では「この PC からリンクを削除する」を選択して外しておきます。

ちなみに、バックアップのつもりで OneDrive を使う場合には、

• デスクトップ PC では、上記のように PC からリンクの解除をしておく。
• ブラウザで onedrive.com を使う

としておくのが安全です。ちょっと面倒ですが、Word/Excel ファイルを操作するときはブラウザ上で、画像ファイルなどはいちいちアップロード/ダウンロードとしておきます。こうすると、PC とクラウド上がうまく分離されるので、Dropbox と同じ形で使えます。

部分的に OneDrive で同期させる

たまに OneDrive の同期が失敗するのが難点ではありますが、部分的に同期させるのがお勧めです（これは、Documents 配下を同期させても失敗は良く起こるので、部分同期でもドキュメントフォルダ同期でも変わりません）。

さきほどの OneDrive の設定から「フォルダーの選択」ボタンをクリックします。

初期設定は忘れてしまったのですが、おそらくこんな感じで「Desktop」「Pictures」「ドキュメント」にチェックが入っているはずです。

よく、OneDrive に騙されるのは、デスクトップを同期に含んだ状態であって、ノート PC のデスクトップからファイルを削除したら、業務 PC のほうからも削除されてしまった。という例です。他にも、ノート PC とデスクトップ PC の両方で別々で作業していたとか、片方でファイルを別のフォルダーに移動したとか、そのようなところで衝突（コンフリクト）が起こって、OneDrive の同期ができなくなってしまいます。最近は、OneDrive が勝手にファイル名を別のものにする機能が加わったので、だいぶんマシにはなったのですが、それでもファイル名がよくわからなくなってどちらが最新なのか混乱してしまいます。
まあ、同時にファイルを弄るのが不味いといえば不味いのですが、ブラウザ上で編集しようとすると、編集できてしまうのが問題ではありますね。

私の場合では、

• Desktop は同期させないので、チェックを外す
• Picture を同期させないので、チェックを外す
• ドキュメントを同期させないように、いったんチェックを外す

すべてのチェックを外したうえで、同期させておきたいフォルダー（下記では、「仕事」と「Blog」）にチェックを入れます。

仕事フォルダは “c:\Users\masuda\OneDrive\ドキュメント\仕事 にフォルダーを作っています。個人用のドキュメントフォルダーとは異なる位置にあります。他にも OneDrive\ドキュメント配下に「公開」フォルダーを作って、その中に Blog を作って、これを同期する形にします。

これによって同期されるフォルダーが「仕事」と「Blog」のみに限られます。
これは新しい PC に Windows 11 をインストールするたびに、やらないといけないのが面倒ではあるのですが、このように同期するフォルダーを設定してしまうほうが制御が楽です。

当然、このフォルダーはバックアップとしてではなく、同期としてつかうので複数台の PC から同期されること（削除や移動など）を意識してつかいます。バックアップとして使いたい場合はあらためて「OneDrive/ドキュメント/バックアップ」のようなフォルダーを作っておけばよいです。

特に、初期値では OneDrive の容量が 5 GB しかないので、ドキュメント全体を同期させてしまうとパンクしてしまいがちです。そのために OneDrive の増設を考えさせられることになるので、ちょっとこれは無駄でしょう。私の場合、以前 40 GB までの無料アップグレードキャンペーンがあったので、最大容量が 40GB になっているので大丈夫なんですが。Microsoft 365 Personal とかを契約したときには、1 TB になるので、契約している場合はいいのですが、素の Windows 11 の場合は OneDrive は使わない方針にして、ブラウザ経由のみで使うのがお勧めです。

OneDrive のその他の使い方

私の場合、OneDrive の仕事フォルダーは各プロジェクト（執筆など）の作業場所にしてあって、出版社との原稿のやり取りや、お客さんとの課題管理表のやりとりに使っています。ぷプロジェクト用のフォルダー移行を相手と共有するようにしてあるので、ファイルをメール等に添付する必要がありません。

会社の場合 OneDrive にセキュリティリスクの高いファイル（設計書、契約書など）を置くのはどうかと思うのですが、さすがに契約書まわりは置かないけれど設計書まわりは置いてあります。こうするとお客とのやり取りが手早いのです。これは Google Claude でもできるので、それでもいいのですが、私の場合は OneDrive で。

補足

Documents フォルダーを同期したままにしておくと、ファイルの紛失もそうなのですが、Visual Studio などで作成した中間ファイルなどが置きっぱなしになっていて、それを同期させて OneDrive の同期が死ぬことになります。ちらほらと Adoble のテンポラリファイルが溢れている例もあるので注意が必要です。

これ、素の Windows 11 の時は容量が 5 GB 程度なので、中間ファイル（Node.js や Python のライブラリも含む）が多くなると溢れてきて気付くのですが、Microsoft 365 を契約していて 1TB に拡張されていると気づくのが遅くなります。ノート PC で同期が走っていてどうもおかしいな？と思ったら OneDrive のでかい同期か Windows Update がバックグラウンドで走っていることが多いです。

震源地は忘れてしまったのですが、「（IT）エンジニアならばソフトウェア工学を知っておいて欲しい」という X のポストだったと思います。ソフトウェア開発するならば、工学的なアプローチも知っておかないといけないのは当然で、まあ、当たり前だよね…と思っていたのですが、意外と「これは、ソフトウェア工学の本だろう」というのが出て来なかったので、備忘録的に書いておきます。

最初に「工学」の定義なのですが、属人性が低く再現性があり量産が可能であることとします。これは、ソフトウェアに限らず、建築、造船、車両技術などを見ればわかる通り、

• 工場で誰もが（一定技術は必要かもしれないが）製品を作れる
• 設計図などがあり同じ製品を作ることができる（これも技術が必要だが）
• 単一でなく、複数のものが作れる

ということです。いわゆる「プロダクト」というやつですね。ただし、IT プロジェクトのように一回性の高いものがあり、プロダクトとプロジェクトを区別することもあるのですが、ひとつ視点を高くして「IT プロジェクトを成功に導く手法あるいは確率的に成功させる方法」として、IT プロジェクトを生産するための「プロダクト」手法というメタ的な考え方ができます。

たとえば、ビルを建築する場合には、それなりの手順があります。基礎を作る、鉄骨を入れるための場所を決めるなどの手順を踏まないとビルは建設できません。もちろん、適当にやってもビルの建築はできるかもしれませんが、確率的にそのビルは崩壊してしまうかもしれません。それよりも、確実に建築できる方法をとるわけです。これがサグラダファミリアも同じで、時間は掛かりましたが（途中ちょっと間違っていたらしいので）、最終的に建築できるものを建築しているという手順や基礎固めがあります。

この手順はソフトウェア開発や運用においても存在します。開発手法として、ウォーターフォール開発やアジャイル開発、スパイラル開発などさまざまな開発手法が提案されて、最近では AI によるバイブコーディングも含まれます。しかし、それらを越えたところに、いわゆる基礎固めとして「ソフトウェア開発プロジェクトを成功させる」ための基礎知識なり知識の蓄積があります。これがソフトウェア工学です。基礎固めなのですから、基礎知識がないとプロジェクトの成功は危うくなります。そういうもので、欠かすことができない要素ということになります。

プログラム言語の本が入っていないのは、ソフトウェア工学自体には特定のプログラム言語は必須条件ではないからです。正確には、プログラム言語という概念が必要になるので、「コンパイラ」の本が必要なのですが、残念ながら私は持っていません。これに適当なコンパイラの本が追加されます。

プロジェクト知識体系 PMBOK（第6版以前）

私自身は PMBOK はあまり好きではないのですが、知識体系として網羅性が高いのでソフトウェア開発に有用です。特に、プロジェクト計画、コミュニケーション、文書管理、調達などの分類がわかりやすいです。ただし、第8版以降は、それぞれのプロセスの実施よりも全体のコンセプトに移行してしまっているので、あまり役に立ちません。アジャイル開発スクラムや CCPM と整合性を合わせたために変な感じになっています。どうせならば、がちがちにプロセス重視でやったほうが PMBOK の有用性は高いです。

PMBOK では全体の要素を網羅するのが目的ですから、それぞれのプロセス/知識分野をすべて同じ力で関わる必要はありません。全体として摘まんでいけばいいんです。ですが、PMP 取得のプロジェクトマネージャがでてくると、PMP の通りにやるのでこれが問題だったのです。最近の PMBOK 系の PM はどうなんでしょうね？

先に書いた通り、PMBOK はアジャイル開発を含むようになっているので、PMBOK（かつてはウォーターフォール開発）とアジャイル開発（スクラム、XP、チケット駆動など）を離反させる必要はありません。全体としてソフトウェア開発のプロジェクトマネジメントという視点で捉えることができます。

UML

設計書を細かく文章で書くことも必要ではありますが、手書き UML だけでも十分なことが多いです。アジャイル開発にしても、開発意図などを伝えるときに UML を使う方がスムースでしょう。いわゆる、建築の三面図や、工作物の図面にあたるものです。

UML は多種にわたっていますが、PMBOK と同様に必要なものとしてつまんでおけば ok です。少なくとも UML を全く知らない、まったく使わない、状態でなければ ok ということです。

私が良く使っているのは、

• クラス図
• シーケンス図
• ステートチャート（状態遷移図）
• オブジェクト図（整合性をあわせるために）
• ユースケース記述

の5種類です。たしか、アジャイル本にも書いたと思いますが、クラス図、シーケンス図、ステートチャート、オブジェクト図は、時間と具象・抽象の2軸で4象限を網羅できます。ユースケース記述は、システムテストに有効なのと、要件定義や検収に有用なためです。

計算機プログラムの構造と解釈

この本は中身が LISP なので読みにくいので、実際はヘネパタ本を使ってください。ヘネパタ本は kindle 版しか手元になかったので、代わりの登場です。パターソン＆ヘネシーの「コンピュータの構造と設計」ですね。

コンピュータの内部構造（CPU、主記憶装置、入力装置、出力装置、補助記憶装置）とレジスタ周りが解説されていれば ok です。論理回路はあってもなくてもいいです。これは論理式で代用ができます。

コンピュータがきっちりと電子と電子回路、バス等で繋がっていること知っておくことは重要です。例えば、CPU と主記憶装置は分離しているので、なんらかのキャッシュが発生します、とかレジスタがありますとかいう話です。補助記憶装置は、HDD、SSD、DVD、データベース などの媒体があり、それぞれスピードが違うのでソフトウェア開発をするときに注意が必要なときがあります、とか。WEB 開発にしても回線のスピードがあるし、データはパケットで送られるから衝突や損失もあるとか。そのあたりが想像できるようになります。

逆に、このあたりのコンピューターの弱点がないものとして「設計」をしてしまうとえらいことになります。当然、要件定義（とくに非機能要件）に関わってくる話です。

ソフトウェア・テストの技法

ソフトウェア開発で、一番ソフトウェア工学らしいのが「テスト技法」の分野です。プログラマ的には TDD（テスト駆動）とかを思い浮かべていますが、いわゆる旧来のテスターや品質管理部門の人達がいる分野です。QA の人たちですね。

このあたり、計測がしやすいので、カバレッジとかコードの複雑度の計測とかいろいろな製品があります。はっきり言って、プログラマから見ると邪魔な存在ですが、必要不可欠な人たちです。テスト駆動の再帰テストはコードが崩れないことを保証するものですが、製品として完成していること＝要件定義などを満たすこと、は保証してくれません。単に動くとか、バグがないとかいうのだけでは駄目で、なんらかの「保証」が必要なんですよね。

これは、自動車の品質管理や安全基準を思い浮かべるとわかります。自動車は動くことは大切ですが、何かにぶつかったり事故が起こったときに人が生き残ることが重要です。これが安全性です。なので、人型に衝突させたり、ボンネットに重たい玉を落としたりします（いわゆる、人間の頭や体ですね）。こういう風な極限状態でも車が安全であることを実験で保証するわけですが、果たして、ソフトウェア開発において極限状態の保証はどうやってやるのでしょうか？　ということです。

つまりは「テスト技法」には、自動車で言う処の極限状態や頻度は低いが重大な障害が発生するところを、工学的に網羅していくという分野です。見知ったところでは、境界値テストとか、負荷テストとか、極限状態のテストです。

ソフトウェア開発の定量化手法

「ファンクションポイント法」を読むと、今更な感じもあり、現在のプログラム言語やライブラリに沿っていないので、あまり意味がない感じがします。実際そうです。そのまま使うことはできません。ここに書いてあるのは、機能単位、コード量などから、プロジェクト計画時に見積もりをしようという発想があります。これが重要な要素になります。

開発プロジェクトが「いつまで終わるのか？」というのは重要な要素です。当然、人件費がかかるので「いくら掛かるのか？」が出てきます。つまりは、計画と予算がプロジェクトの開始時に必要なわけです。官庁の見積もりでもそうですが、事前にスケジュールと予算が必要になります。でも、実際作ってみないとわからないですよね。でも、走り出す前に計画と予算を出さないといけないのです。実に矛盾しているように見えるのですが、これは建築や土木、車両の分野でも同じです。事前に見積もりを出します。

ビル建築の場合は、部材ごとに見積もりを出して合算していきます。それぞれの工法には施工期間が事前にわかっているのでこれで期間を見積もれます。途中に天候の問題などがありますが、それは余裕を持っているのであまりずれることはありません。まあ、沖縄の普天間基地の移転のように岩盤の調査をミスったりするとずれてしまうわけですが（それが意図的であるかどうかは別として）

ソフトウェア開発は複雑度が高いので、正確な見積もりは出しにくい。というのがソフトウェア開発におけるマネージャ、プログラマの意見ですが、だからといって目途を全く立てないという訳ではありません。実は、そこそこのプログラマはいつごろまでプログラムができるかを、的確に予想してコーディングすることができます。おそらく、経験と勘なのですが、なんらかの形で「定量化」することができます（実際は、PSP（ソフトウェア・パーソナル・プロセス）を使って測定できます。しかし、しんどいので私はあまりやりたくありません）。

つまりは、何かを基準にして（それが経験と勘であったとしても）何らかの法則で計算することによって、プロジェクトが計画可能であることを示すのが、定量化手法のベースです。逆にいえば、何かの基準を持たない人（新人や、コーディングをしないマネージャなど）は計画を立てることができません。このあたりの弊害は「BIG THINGS」に書いてあります。

ソフトウェア開発見積りガイドブック

定量化手法は、規模見積の話（いわゆるスケジュール）になりますが、この本では予算の話になります。ベースは定量化と同じようにファンクションポイント法などを使って計算をしていきます。

いままでは、プロジェクトの期間は、人月を掛けることによって予算に直結していたのですが、最近は異なります。高度なライブラリを使ったり、これからは AI エージェントを利用したりと、期間とは異なった形でプロジェクト予算が変わってきます。つまりは、建築でいうところの部材調達の比率が大きくなるということです。クラウドの利用料や特定の UI システムの利用、SAP や Microsoft 365 などの継続利用料というものが関わってきます。

つまりは、同じ要件定義でもなにかのライブラリを使うとか使わないとか、クラウドを使うとか使わないとかの形で、開発費用や運用費用が異なるということです。これらの状況はガイドブックができた頃にはなかった話なのですが、意味合いとしては昔からありました。

そのように必要な人件費とプロジェクトが活用する設備費用を合算していきます。当然、運用時の費用も計算します。これは PMBOK にあるのですが、定量化や金額見積もりの具体的な方法については、この2冊が非常に詳しいです。内容は古いのですが。

コンパイラ

写真にはでてきませんが、「コンパイラ」について挙げておきます。プログラムコードがそのままコンピュータで実行されるわけではないこと、その前にコンパイル作業が必須であることを理解できるようになります。

プログラムコードの文法、字句解析、文法解析、中間言語、マシン語への変換、などの流れを知っておくと、プログラムのコードがどう動くか？だけではなく、どのように最適化されるのか、なぜそのような文法になっているのかを知ることができます。これは、プログラム言語に関係ありません。中間言語で動く Java や C#、スクリプト言語として動く Python や JavaScript など（正確にはプリコンパイルなどの機能がありますが）の内部の動きを把握することで、単なる抽象概念としてのプログラム言語ではなくて、具体的な制限のあるプログラム言語を知ることができ限界値がどこにあるのかを気にするようになります。

たとえば、いろいろなソートアルゴリズムがありますが、それがなぜ「いろいろ」なのかということです。抽象的なメモリ配置ではなくて、具体的なメモリ（架空ではない）をアクセスしているので「いろいろ」になるのです。その感覚を養うために「コンパイラ」のざっとした知識が必要になります。

大学時代に読んでいた「コンパイラ」はこれですね。著者は aho だったのか。

おまけ。こっちのコンパイラも。

小説を書くならば小説を読んだ方がいいし、絵を描くならば絵を見たほうがいいです。当然、最終的には小説を書いたり絵を描いたりすることが目的なのですが、なにも吸収しなければ何も出て来ない、というのが常ですね。たまに、小説も絵も見ないで書/描ける人もいますが、それは例外的な人なので、一般的な話として制限しておきます。
あと、将棋がうまくなるのも、将棋の棋譜を読むのが重要なので、やたらに将棋を指すだけではいけません。棋譜を読むのもひとつの手です。

自分の経験上でも、良質のコード読むのが手っ取り早いです。私が駆け出し＝つまりは会社に入って新人のプログラマだった頃には、インターネット等は無かったので、主に参考にできるのは、少ないコンピュータ書籍とマニュアル、そして既存のコードでした。まだ、コンピュータ書が少なかった時期なので、プログラム言語（VB2.0 や C++ の頃）を学ぶにはマニュアルしかなかった時代があります。もっとも、既に C 言語や Fortran の書籍はいくつかあったので、初心者本というか教科書は手元に置いておきます。当時 VB2.0 はまだ新しかったので、参考にできる書籍はなくマニュアルが頼りでした。

あとは、既存のコードとなるわけですが、果たしてそれが良質なコードであるかどうかはわかりません。今考えれば、とんでもないクソコードだった気もしますし、新人だった当時も私もクソコードを書いて納品していた覚えがあります。まあ、C++ にかぶれていた時期があるので、現場は Unix C なんだけどオブジェクト指向（のつもり）で書いて、実に読みづらかったんですよ。他人が読めるってのは大切です。特に、当時はコンパイルのスピードも遅かったし、テスト駆動以前の時代だったので、紙面でのコードレビューは重要でした。それでも、会社の先輩のコードは「読む」のが普通で、そうしないと仕事にならなかったですよね。

あと、私の場合は “コードを読む” ことに関しては、

• 大学時代に、炉計算の Fortran のコードを読む必要があった
• OpenSSL を修正して検証ツールを作る関係上、OpenSSL のコードを読んだ

ってのが大きいです。炉計算は日立の技術者が作ったもので、これを修正するのが自分だったので読まざるを得ませんでした。OpenSSL は、ガラケーの暗号化のテストツールなのですが、データ解析するために OpenSSL を使ってデバッグコードや特殊なスイッチ（証明書の不正など）を入れざるを得ませんでした。

どちらにしても、大量の “良質な” コードを読まねばならず、これが幸いしたと言えます。

ただし、この方法はいまとなっては効率が悪いです。当時としてもどうかと思うけど、読むにしてもいきなり OpenSSL は大変です。GNU ツールのいくかから始めたほうがよいでしょう。

今だったら何のコードを大量に読むか？

いまだったら GitHub にある OSS のコードを読みます。プログラム言語は JavaScript でも Python でもなんでもいいのですが、できることならば IDE でデバッグ実行と変数が見れるようなプログラム言語がいいです。プログラムをステップ実行して、メモリの中身を確認できるものがいいですね。
まあ、そうなると Python と JavaScript はあまり適してはいないので（ステップ実行できるツールをもっていれば、それでもいいです）、Java とか C# のほうがやりやすいですね。コマンドラインツールでも GUI ツールでも途中でプログラムを止めて中身を確認することができます。ただし、仕事の都合上、React での Web 開発や、Python を使った科学計算をすることも多いでしょう。そういう場合は、真っ先に print デバッグの手法（JavaScript ならば Console.log 、Python ならば print）を覚えて、動作をログ出力しながら動きを確かめていきます。

仕事で使うコードが OSS のプログラム言語とは異なっている場合は、AI チャットを使ってコンバートしてもらうのも良いです。プログラム言語は、似たような文法が多いので（英語、フランス語、ドイツ語の関係のように）ひとつのプログラム言語を覚えておけば、他のプログラム言語を覚えやすいという傾向があります。
いままでは、初心者本を一冊買って文法を下読みするのですが（私の場合は今でもそれをやりますが）、いまだと AI のチャットを使って、コードを変換してもらうといいです。
AI のプロンプトで「○○言語に変換して」と頼むと、高確率できれいに変換してくれます。
当然、固有のライブラリまでは変換してくれないので、これは別途探す必要があります。あくまで、プログラム言語の文法やいくつかの構文の使い方を学ぶときに使います。

固有なライブラリを使っているときは、変換先の言語で適当なライブラリを探して貰います。そして、そのライブラリの使い方についてサンプルコードを AI に書いて貰います。
ライブラリ込みで変換することも可能なのです。が、AI エージェントだと結構な確率で変えてくれるのですが、コードが長くなり複雑になりがちで学習には適してはいません。できるだけ、ライブラリはひとつに限定して確かめていったほうが良いです。
プログラム言語の歴史として、手続き型、構造化、関数型あるいはオブジェクト指向、という形で進化してきているので、最初は手続き型の文法（if文やfor文など）を覚えたあとで、構造化（関数の使い方、構造体の使い方）を学ぶとよいです。その後、状態（ステート）について、オブジェクト指向型を使うか関数型を使うか選んでください。Web API の呼び出しは、構造化のレベルで十分可能なので、オブジェクト指向/関数型言語を最初のうちは意識する必要はありません。
効率よりも、確実に動くコードを目指していきます。

自分で書いたコードは、逐一 AI にレビューして貰うといいです。仕事でチーム開発をしている場合はレビューがあると思いますが（いや、無い場合も多いのでしょうが）、少なくともプログラム言語の学習をしている間にレビューを頼むということはほぼ不可能です。プログラミング教室に行って高いお金を払ってレビューして貰うことも可能ではあるのですが（最近 X では聞かなくなってしまったので、プログラミング教室が駆逐されたのか、果たして…）、AI にレビューをして貰ったほうが安価だし手軽です。
ただし、AI を使ったレビューにしても冗長なところが多いので、いまひとつ何を言っているのかわからないと思います。このようなときは、書き出した全体のレビューを AI に頼むのではなく、部分的にコードを選択して AI にレビューを頼むと良いです。この方法は、仕事でもよくやります。Agent モードを使うとコード全体を直しがちになるので、Ask モードを使って部分的な関数やコードをレビューして貰います。
特に、自分にとってあまり詳しくない言語にはこれが効いてきます。仕事でも Kotlin/Swift のコードは部分レビューを多用しています。

昔風に、コードを精読するのもいいのですが、もっと大量に多読する形でもよいです。

ちなみに、小説ですが私の場合は2,3か月程度で、こんな風に多読をします。金銭的には新刊で買うと辛いので BOOK OFF 等で 100 円程度で買ってきます。いわゆる乱読を意識的にやります。1冊読むのに、1,2日間ぐらいで時間で言えば、2時間弱位の流し読みです。これで文章のパターンを覚えた上で、もろもろの短編を書く、というのを今やっています（乱読自体は20歳代のころからやっているのですが、それは書評日記を書くためだったりするので、ちょっと違う）

上記の学習方法については、以下の本に書いてあります。これは Python がターゲットなのですが、他の言語でもいけますね…って形で書いたんですが、意外と売れないので次がありません（汗

まあ、Python 自体を学ぶのではなくて「Python の学び方を学ぶ」という手法を実際に示したものなので、読むと「いままで AI を使って学んできたやりかたと同じじゃん」という感想しになってしまうのも無理からぬことです。既に AI を使った学び方を知っている人じゃなくて、知らない人向けなので、既に知っているひとにとっては not for me なんですよね。

spec 駆動のエディタ（Claude xxxx とか Codex とか Kiro とか）流行りなのですが、それ vscode + copilot でやることもできます、って話です。夜間にぐるぐる回すようなヘビーな使い方をする業務型プログラマならば別ですが、それほど AI に任せきりではなく AI ペアプロぐらいな形で廻している場合には、課金的にはこっちのほうで十分です。まあ、開発のスタイルにもよるんでしょうけど、React とか Node.js を使った Web 開発のほうは Codex 系でぶん回したほうがいいのでしょうが、Android 実機で BLE 通信を確かめるとか（ってのを今やっている）のは、どうしても実機まわりのテストを手動でこなさなくてはいけないので、AI でぶん回すことは無理なのです。

あと、当然のことながら、

• 趣味でプログラミングをやる
• 在宅プログラマで、いくつかの案件を廻している
• 新人教育で AI を使ってプログラミング学習も兼ねる

というパターンも、vscode + copilot で十分です。GitHub Copilot のほうは pro で十分で月額は $10 で…という宣伝はどこかに書いたような気がするのでさておき、ここでは「設計」と「実装（コーディング）」を分離させていきましょう、という話です。

Windows Copilot がやたらに実装を勧める

プロトタイプを作って動きから確認したい場合には、要件や設計を煮詰める前に実装を始めてしまうほうが楽です。というのも、具体的に UI が決まっていないのに、長々と要件/設計を煮詰めてしまうと、余計な設計をしてしまいがちです。そのあたりは、スパイラル開発あたりを参考にしてください。

昨今の spec 駆動型エディタは、要件/設計を先に煮詰める形になっていますが、これはいわゆる「ワンパス」方式になります。いわゆる、コンパイラ設計でコードからアセンブラに落とすときの「ワンパス」つまり一回しか読み込まない方式です。要件/設計 → 実装の一手順だけを考えれば、要件/設計をしっかり作る＝夜間に AI にコード生成を頼む、ということになるので AI の時間一杯を使うだけの設計の盛り込みが必要になりますが、先のように設計→実装→UI 確認→設計→実装 のサイクルとなると、それほど設計の作り込みは必要ありません。と言いますか、余分なところが多く出てしまいます。

ただし、ここのサイクルが廻る開発/実装環境と、そうではない環境（先の Android 実機でのテストなど）では、プロトタイプサイクルの時間が異なるので、設計と実装の時間比とバッチ（いわゆる実装する機能の大きさ）を調節する必要があります。

で、Windows Copilot などで、コード開発をしようとすると、やたらにコード例を示してきます。どうも、React + Fagma の組み合わせや Python 開発が最初に出てくるので、この開発スタイルに引きずられてしまいます。一般的な AI 驚き屋の対象も Web 開発になるので、確かに UI から考えていったほうが検討上早いというのもあるでしょう。実際 Web サイトの自動開発はとてつもなく早いです。Windows Copilot や、その他の AI エージェントも Web 開発を前提としているものが多いのでしょう。

ですが、非 Web 開発の場合には、機器などをそろえたり環境を揃える必要があるので、そう簡単に実験環境が揃えるわけでもありません。特に AWS や Azure の環境にないものを使う場合は、環境構築も含めて検討をする必要があります。そういう点で、「設計」に力点を置いたほうが、ソフトウェア開発において無駄が少なくなる、というバランスになるのです。

設計と実装をプロンプトで分離する

ちょっと前までは（それも数か月前ですね）、spec 駆動は別の AI エージェントの IDE を使っおいて、コーディングは Claude xxxxx や Codex に任せる、というスタイルが多かったのですが、現状だと vscode + copilot ひとつで済みます。これ、vscode + copilot に agent モードが追加された（それまでは ask モードとして質問だけだった）ことが大きくて、これによって、

• 要件や設計を煮詰めたいときは ask モードでやる
• 実装やバグ直しをしたいときは agent モードでやる

という使い分けをします。ask モードの場合は、最初の頃はコードをばらばらと出してくるのですが「コードをの提案をしないで」とか「設計に集中して」というような、プロンプトを入れるとコードの提案をしなくなります。おそらく model の内部的に、コードの部分は codex で、それ以外は chatgpt で、という使い分けがなされているからと思われます。

さらに、再設計時には AI にコードを触れてほしくないので、敢えて ask モードを使います。ask モード自体は、従来のプロンプトで質問して、その解答をテキストだけで表示するモードでコードに反映するのが手間だったりするのですが、敢えてこれを利用します。思考したいだけですので、AI 壁打ち状態とするわけです。

実例

以前、ためしに作ってみた「見積もり依頼作成ツール」 https://omitt-chan.vercel.app/ を変更してみましょう。これも AI エージェントを使ったもので、基本的に次のような readme.md を使って、初期型を作っています。

# omitt-chan

見積もり依頼作成ツール

- 発注者が、みずから希望する機能を入れて見積もり依頼書を作る
- 見積もり依頼書のテンプレートを提供
- 作成した見積依頼書をもとに3パターンの見積もりを作成する（相見積に使う）

# 画面構成

- 左ペインに、発注者が対話的に入力するチャットフォーム
- 中央ペインに、発注者が入力した要件や機能を構造化して表示する
- 右ペインに、見積もり依頼書のテンプレートを表示する

## 要件チャット（左ペイン）

- 発注者は、チャット形式で要件や機能などを入力する。
- 発注者は非IT技術者のため、自然言語で要件を入力する。
- 希望、要件、設計、制約などは混在して入力されるため、入力内容を解析して構造化する必要がある。
- 発注者の入力を解析して、要件や機能を抽出し、中央ペインに表示する。

## 要件整理（中央ペイン）

- 中央ペインでは、発注者が入力した要件や機能を整理して表示する。
- 要件と機能を区別して表示する。
- 機能は、機能要件と非機能要件を区別して表示する。

このときは、readme.md に書いていたのですが、design.md とか設計.md とかでも構いません。ファイル名は、プロンプトから「design.md をもとにして Web サイトを作成して」で指示ができます。

ここでは、機能追加をする上で、どのような設計がよいかを readme.md に手作業で追加していくことを考えます。

こうやって、見積もり依頼書ができた後に、おおまかな予算を顧客側で把握したい、と考えます。

設計に適していると思われる CPT-5 に変更して、Ask モードに切り替えておきます。

追加機能を書きたい場所を、readme.md 等に作っておきます。
ここでは「概算予算の計算」という項目を作りました。

プロンプトで、追加機能を設計していきます。

初期状態だと、コードが大量にでてくるので、これをプロンプトで抑制します。

プロンプトで抑制すると AI の回答にコードが含まれなくなります。安全のために Ask モードのままで会話します。

以降は、コード無しで会話ができます。機能追加の検討でも、やたらにコードを出すことはありません。この分、トークンの消費も少ないし、レスポンスも早くなります。まあ、Agent/Ask の切り替えが面倒というのもありますが、そこまで開発スピードを求めるならば別途 SPEC 用の AI エージェントを使えばよいわけで、私のような使い方だとこれぐらいで十分かな、という感じですね。

あとは、Chat での検討に従って、readme.md に追記していけば ok です。このときに Agent モードに切り替えてもよいし、markdown 形式への補完をつかってもよいでしょう。

その後に、あらためて「概算予算の計算を Web サイトに追加して」というプロンプトを Agent モードで Copilot に頼めばよいのです。

もちろん、一手順ずつうごくので夜間で バイブコーディングとして動かすことはできません。ですが、要件や設計を試行錯誤しながらスパイラル開発っぽいものをやる場合には、このスタイルのほうが良いです。