  |
はてなキーワード: 粒度とは
ある音楽家が、これまでのリリース作品がすべてAIベースの制作環境で作られていたことを、その環境を商品として販売開始することで明かした。
この記事は、それを告発するものではない。むしろ、その製品が宣伝通り機能した場合にこそ私たちが直面する問い——「感動していた曲は、何によって作られていたのか」「作曲がプロンプト設計に移るとき、聴き手は何を聴いているのか」——について、ひとりの聴き手/作り手として考えたことを書いておく。
1～4節はその商品の分析がメインなので、ゴシップ的な話に興味のない人は5～7節だけ読めば十分。
Twitterで、気にかけていたアカウントがあった。フォロワーは二千人規模だが、Hyperpop以降の日本のシーンで頭角を現している一人、という認識が自分の中にあった。界隈の主要な音楽家たちからもフォローされている、といえば規模感が伝わるだろうか。リリースされる曲には、たんに「いい音楽」と片付けるのは難しい構成の巧妙さと音選びの新しさがあって、追ってはいないまでも名前は頭にあった。
そのアカウントが最近、自分の制作環境を商品として販売し始めた。価格は14,900円、「AI音楽制作環境」として売り出されていて、製品ページの宣伝文句はこうなっている——「『気持ちよくて驚きのある曲を作って』——そのくらいの指示から、コード進行・歌詞・Sunoプロンプトまで一貫して出力します。」さらに、既発のアルバムとEPは「全てこれを軸に制作されている」とも明記されていた。
最初に湧いた感情は、「ああ、そういう工程で作られていたのか」という、ある種の冷めの感情だった。AIを使っていることそのものへの反発ではない。SunoのようなAI音楽生成ツールの進化については以前から耳にしていた。出力自体のクオリティを否定するつもりもない。そうではなく、「何に対して感心していたのか」という、自分の受け取り方の根元が揺らぐ感覚、とでも言えばいいだろうか。
この感覚を、個人的ながっかりエピソードとして飲み込んで済ませてもよかった。けれど製品ページを読み進めるうちに、これは自分一人の話ではなく、いま音楽を聴く/作る側に共通してくる問題になっていくだろうと思い直した。以下はその整理になる。
製品ページから読み取れる範囲で、何が売られているのかをまず整理しておく。評価は後回しにする。
製品としての訴求は、おおむね三層からなる——(a)独自の音楽生成エンジンであること、(b)感覚的な指示から完成物が自動生成されること、(c)学習ツールとしても機能すること。
実際に買って触ったわけではないので、以下は推測の域を出ない。ただ、製品説明を読み解くと、構造的にいくつかの疑問が浮かぶ。
まず、''「Python疑似コード」という語の含意''について。「疑似コード」はPythonの形で書かれていても実行されないテキスト、つまり構造化されたプロンプト/参照資料のことを指すのが通例だ。Claudeプロジェクトに.zipをアップロードする形式である以上、これはClaudeが読み込むルール文書群であって、独立して走る独自エンジンではない可能性が高い。MIDI出力部分などは実行可能コードだろうが、「コードを選ぶ」「歌詞を書く」といった音楽的判断のコアは、Claude本体の自然言語推論能力が上限になる。これ自体は悪いことではない。よく練られたプロンプトパックは、Claudeの出力の一貫性と専門性を上げる。ただし「独自エンジン」という響きが含意するものとはかなりの距離がある。
次に、''Sunoへの依存度''について。製品の主要アウトプットのひとつが「Sunoプロンプト」である以上、最終的に音として鳴る部分——音色の質感、ミックスのバランス、演奏のニュアンス——を生成しているのは、この製品ではなくSunoのほうということになる。つまり、この製品の価値の相当部分は「Sunoを上手く使うためのプロンプト設計の職人技をパッケージしたもの」であって、Sunoが進化すればその層の価値は急速に目減りする。
三つ目に、''「all built by hand」の含意''について。86,000行という規模が、本当に人間が手で書いたものなのかは、製品説明からは判別できない。ジャンル研究ノートやStyle語彙データベースといった文書は、AIに「このジャンルについて詳細なルール文書を書いて」と指示すれば相当量が出てくる種類のものである。骨格は人間が作っていたとしても、肉付けをAIに任せている可能性は十分ある(そしてその場合、「手作業で書いた」という説明の重みはかなり変わってくる)。
繰り返すが、これらは推測にすぎない。実際に買って開ければ印象が変わる可能性は十分ある。ただ製品ページの記述だけを根拠に判断する限り、「独自の音楽生成エンジン」「作編曲の学習ツール」という訴求は、実態を控えめに言っても過剰包装しているように見える。
この製品に対する考えられる反応は、「宣伝通りに動くのか？」という疑問だろう。
しかし、立ち止まって考えると、本当に問うべきは逆側であることがわかる。
仮にこの製品が宣伝通りに機能するなら——「気持ちよくて驚きのある曲を作って」という指示一行から、コード進行・歌詞・Sunoプロンプト・MIDI・MP3まで一貫して出力されるなら——自分が感心していた曲は、その程度の指示から出てきたものだった、ということになる。下準備としての疑似コード整備や、出力に対する微調整は当然あるにしても、一曲一曲の制作工程の中心がそこにあったのなら、感心の源は作り手の耳ではなく、ツールの出力分布の中にあったことになる。たしかに創作物は優れていたかもしれないが、「それが優れていたのは上手くSunoを使いこなしていたから」という、エンジニアリングの問題だったということになる。
機能しないなら誇大広告の問題で済む。機能するならば、「聴き手は何を聴いていたのか」という、より根本的な問いが立ち上がる。皮肉なことに、製品としての完成度が高いほど、この問いは重くなる。
ここで思い出しておきたい話がある。2023年のゲンロンのイベントで、音楽家のtofubeatsが、Spotifyのサジェストで流れてきた曲に心を動かされ、作曲者を調べたらAI生成曲だと知って深いショックを受けた、という経験を語っていた。彼自身がオートチューンで声を加工し、歌声から人間性を排して作曲するタイプの作家でありながら、である。「非人間的な曲が、本当に人間によって作られていないこと」が判明したときの空虚さを、彼は正直に語っていた。
この空虚さが何から来るものなのかは、6節でもう少し踏み込んで考えてみたい。ただ先に言っておくと、それは「AIは音楽を作ってはいけない」という種類の話ではない。むしろ、「聴くとき、自分は何と対面していたつもりだったのか」という自己認識の問題になる。そしてそれは、作り手が工程を開示しないまま商品を売り始めた瞬間、聴き手の側で解決することが不可能になる種類の問いでもある。
誤解されたくないので、はっきり書いておく。この文章は、AIで音楽を作ることへの全面的な否定ではない。
作曲の歴史は、すべてを人間が設計し人間が作る歴史だけではなかった。偶然性、システム、自動化、外部の力を取り込む試みは、ジョン・ケージから、ブライアン・イーノ、アルゴリズミック・コンポジションまで、20世紀以降の音楽史の重要な部分を形作ってきた。AIの導入はその系譜の延長にあって、それ自体を否定するのは筋が悪い。
近年の例で言えば、菊地成孔は自身が主宰するギルド「新音楽制作工房」でAIを活用していることを早くから公言している。NHKドラマ『岸辺露伴は動かない』の劇伴ではMaxを用いたAI生成による弦楽四重奏が使われており、菊地本人が「作曲者のクレジットもないし、著作権のありかがわからない」という問題をNHK出版経由でJASRACと協議し、「新音楽制作工房」名義のクレジットで処理することで決着させた、という経緯まで公にしている。つまり、どう使い、どう扱い、誰の名のもとに出すかを、彼は工程ごと開示している。
ここでの違いは、「AIを使うか使わないか」ではなく、「どう使い、どう開示し、何を自分の名のもとに出すか」にある。「AIの使用は隠していない」という表明と、「どの工程をAIに委ねたかを開示する」こととの間には、大きな距離がある。
そしてもうひとつ、避けて通れない論点がある。Sunoを含む音楽生成AIが、何を学習データにしているかという問題だ。2024年6月、RIAA（全米レコード協会）はSony Music・Universal・Warner Musicを代表してSunoとUdioを著作権侵害で提訴した。Suno側は、レコード会社の著作権で保護された録音物を使用したことを概ね認めた上で、フェアユースを主張している。2025年末にはWarner MusicとSunoがライセンス提携で和解したが、訴訟全体はまだ決着していない。
つまり、いまSunoで曲を作って発表することは、その学習データが何で、どのような経緯で集められたかが法的に争われている状態のモデルを使うことを意味する。これは「使ってはいけない」と言いたいのではなく、「自分の作品がどういう供給ラインの上に立っているか」を無自覚なままにはできない、ということだ。そして、そのモデルを使って生成した曲で「作曲者」を名乗り、その制作環境を商品化して収益化する、という連鎖の倫理性は、まだ業界全体として合意が取れていない。
この記事の射程は、その倫理そのものを裁くところまでは届かない。ただ、「いい曲さえできれば制作過程はなんでもいい」という論法に、即座に頷くことはできない、という姿勢だけは明示しておきたい。
ここで、4節の末尾で保留にした問い——tofubeatsが味わった空虚さは何から来るのか——に戻ってくる。
創作物を聴く側は、作り手の工程をつねに見ているわけではない。それでも、作品を受け取るときには「制作への真摯さと、出来上がった作品のクオリティは、どこかで結びついている」という、いわば感覚的な信頼をもって聴いている。これは創作と鑑賞の間に長く存在してきた暗黙の契約のようなもので、あるシンガーソングライターが書いていた通り、手間暇掛けようが掛けまいが最後には一緒くたに扱われる時代でも、違いの分かる人はいるはずだと信じて丁寧に拵える——という姿勢を、作り手と受け手の双方が（明示的ではないにせよ）共有してきたから、音楽は単なる音の配列ではなく、作り手の痕跡を伴うものとして聴かれてきた。
AIが生成した音楽そのものにも、それ独自の良さがある。これは繰り返し強調しておく。作品としての良さは、工程とは独立に成立し得る。ただし、AI生成された曲を「ひとりの作家が作った作品」として提示し、その仮構された人格のもとに人気を集めることは、この暗黙の契約を根元から破壊する。聴き手が「これを作った人は、たぶんこういう感受性の持ち主なのだろう」と想像しながら聴いていた対象が、実は大部分がプロンプトから生成された出力だったとしたら、その想像は宙に浮いてしまう。作品が悪かったわけではない。悪かったのは、作品と作り手の人格の間にあったはずの関係について、聴き手が抱いていた前提が、工程を開示されないまま利用されていたことにある。
tofubeatsが味わった空虚さは、たぶんこれに近い。「AIが作ったから価値がない」ではなく、「自分は作品を通して誰かの感受性と向き合っていたつもりだったが、その『誰か』が自分が想像していたものとは違っていた」という、受け手側の文脈の宙吊り。この宙吊りは、作り手の側がAIの使用を大まかに表明するだけでは解消されない。「何を自分の判断で選び、何をツールに委ねたか」という工程の粒度での開示があってはじめて、聴き手は自分の感心の行き先を再設定できる。
この視点から見ると、今回の製品販売で起きたことの構造が少しはっきりする。14,900円という価格や、買った人にとっての有用性の問題はもちろんある。ただ、それ以上に大きかったのは、制作環境を商品化するという行為が、既発の作品群を「この環境の実例」として遡行的に位置づけ直してしまうことにある。以前から作品を聴いていた側から見れば、聴き手と作り手の間に結んでいたはずの暗黙の契約の内実が、後出しで書き換えられる感覚がある。
制作工程の開示は、法的義務ではない。ただ、制作環境を商品として売り始めた瞬間、この暗黙の契約を自分から前景化させたことになる。「この環境でこれだけの作品が作れる」という実例として既発のリリースが参照されているのなら、それぞれの作品がどの程度この環境の出力そのものなのか、どの程度は人間の介入によるものなのかは、買う人にとっても、これから聴く人にとっても、重要な情報になる。
最後に、聴き手として、作り手として、これからどうするかを書いておきたい。
聴き手としては、tofubeatsが味わった種類の空虚さを、できれば避けたいと思うひとが大半だろう。しかしtofubeatsがAI生成だと気づくことができたのはクレジットにそう明記されていたからに他ならない。今回の私のケースのように、AI生成であることが明かされていなかったり、将来的に（遡及的に）AI生成であることが明かされるようなパターンはますます増えていくだろう。私たちは、匿名性を保ったままクオリティで勝負して有名になっていくという同人音楽シーンの時代の終焉を目の当たりにしているのかもしれない。作り手と受け取り手の信頼関係が壊れていくなかで、聴き手側からできることはあまりにも少ない。界隈で有名なコンポーザーの多くも今回のアカウントをフォローしていたことも考えれば、制作過程の情報開示を積極的に求めていくこと、プロセスを明らかにしたうえでよいものを作っているひとを評価していくこと等も、その限界は大きいだろう。
作り手としては、自分がやりたいのは、プロンプト一行から出てくるものを受け取る側ではなく、一音ずつ選ぶ側である、とあらためて確認した。それはAIを使わないという意味ではなく、AIを使うにしても、どこで自分の判断を通すかを意識的に設計したい、ということになる。菊地成孔のやり方に近いと言えば近い。作編曲に限らず、これまであらゆるアートと呼ばれる領域について、過程を見せないことは作家の神秘性を増すための重要な要素だった。しかし上にも書いたように、その限界はもうすでに見えてきているように思う。過程を明らかにしたうえで、自身の武器がすべて明らかであるのにそれでも真似できない創造性を見せること。もちろん、あらゆる出力結果は機械学習の餌食になりうるという状況においてこれは綺麗事かもしれないが、成果物がいわゆるAIに食われうるのは変わらないのだとしたら、いかに自身の制作においては透明性を保ったうえでクオリティで受け手を納得させるか、こそが大事になってくるだろう。こうしたムードを作り手の側からも作っていくことが、今後の大きな課題になるのではないかと思う。
「AIがもっといいものを作れるのになぜあなたが作る必要があるのか？」は、「プロの作家がすでにこの世に五万と存在するのに、なぜあなたは作品をつくろうと、その道を志したのか？」という問いと本質的には何も変わらない。作りたいから、作る。伝えたいから、それを形にする。そうした初期衝動が、欲望が、「創造性」という言葉の本質であり、AIに模倣することのできない、あなただけの、私だけの創作物につながるのだから。
前回(https://anond.hatelabo.jp/20260318165937)
3回目です。ささやかな抵抗として米国系インデックスへの投資を止めました。いくらか今まで儲けさせてもらった分は支援の意味も込めて日本市場に回そうと思います。
あまりにもいろいろ目まぐるしいので、ささっと思いつく部分をなぐり書きしていきます。
・3/27午後現在
本格的に材料系の値上がりや減産の話が揃ってきた。各種業界紙や日経新聞とかで確認してください。
ここ2-3日でホルムズを通峡する船が若干増えた。パキスタン、インド、中国などイランと敵対してない国向け。昨日はブラジル向けのバルカーも1隻。ブラジルは一貫して反トランプを主張しているのでそのためだと思う。マレーシアもいけそう?
日本以外のアジア各国でロシア原油購入の動き。苦しいけど仕方ない。ただウクライナがロシアの大規模精油所を破壊したので、どのような調達になるか不明。
日本の原油代替調達も僅かだが実績がつき始めている。ゼロじゃないこと自体が希望。
韓国は政府主導で節約モードに移行。これまで輸出していた精製品も国内向けに止めてきているので、日本にも影響あり。
日本はパニック買いや節約不況を警戒しているように見えるが、石油関係の事業者や閣外の議員からも節約すべきという意見が出てきている。個人的にも同意見。
ただコロナ初期のような厳しい自粛ではなく、ちょっとした家庭の無駄遣いや自家用車の節約といったスモールスタートでいいと思う。とはいえ来月からすべてが値上がりしまくって勝手に節約モードになると思うけど。
物品の生産は夏までが勝負になりそう。あまりモノがないと治安も心配になるので、細く長く生き延びる社会体制を整えてほしい。
そして世界トップクラスの備蓄体制を進めてくれた50年前の人たちに感謝。
・戦況
今日の夜(=アメリカの金曜の日中)にアメリカがどう動くか。今朝からペンタゴンへのピザデリバリーが売れまくっているようなので、地上侵攻だけが大きな懸念。ど素人から見れば全く楽勝に見えないんですが本当にやるんですか?
一方で周辺国からのイスラエルへの非難も増えており、アメリカだけを気にすればいいものでもないことは世界中で理解されているように思う。
・情報源
大手ニュースサイト以外で増田がチェックしている情報源は以下のとおり。
LogisticsToday(物流全般のニュース 解説も詳しいが、若干悲観寄りに見える)
赤沢りょうせい(経産大臣 トランプ関税以来ずっと日本経済の柱)
妙に石油に詳しいフリーザー(石油現場に近そうな人 大変そうだがいつも冷静)
とし山とし夫(何やってる人かよくわからないけどいつも前向きなので、落ち込んだ時に見る)
毎日どころか数時間ごとに特大級のニュースがあるせいで、アルジャジーラやロイターですら情報の粒度を揃えられずなんでもかんでも速報扱いで流している。時々不正確なニュースもあるので、ショッキングな内容ほど気をつけたい。
それと時差のせいで日本時間の深夜に新しい情報が入るので日本の夜のニュース番組が1日遅れくらいになっている点は留意したい。既に周回遅れになっているのを何度か見た。
かといって深夜に海外ニュースに張り付くのも精神によくないので、節電と割り切って少しでも早く寝た方が良いでしょう。
株や金融関係のアカウントもあまり見ないほうがいい。全体的に悲観的、大げさな情報発信が多くメンタルに良くない。
それにトランプの発言に対して市場の反応も鈍くなってきているので深追いしないほうが精神に良い。アジア圏にとって今大事なのは市場ではなくモノの流れです。
・やることと希望
さっきの早く寝るのにもつながりますが、事故や病気には気をつけたい。病院で大きな怪我や病気がうまく治療されない可能性も上がってきています。こういう時こそ心身の健康大事です。
あとは官民の最前線の人たち(とその家族)の力を前向きに信じましょう。増田も仕事を通して0.000001%くらい社会貢献するような雰囲気になってきてます。
無も知らぬ皆さんにおかれましてもなんとかやっていきましょう。
知識の伝達は、もう壊れる。
これまでIT業界は、一次情報のまわりに二次情報と三次情報を無数に積み上げて回ってきた。
誰かが何かを作る。すると、その周りに「やってみた」「初心者向け」「3分でわかる」「完全解説」が何十本も生える。
しかも大半は、発見者でも設計者でもなく、昨日知った人が今日教えている。
その役目は終わる。
要約、翻訳、言い換え、文化圏ごとの変換、レベル別の説明は、全部LLMが担う。
残るのは一次情報だけだ。
QiitaもZennも技術ブログも残るが、誰も読まない。書いた人の痕跡として残るだけになる。
教科書も同じように分解される。
本文は消える。
残るのは体系だけだ。
概念の依存関係、粒度、階層、グループ、到達目標、この骨格こそが本体だった。
もちろん、その体系は万人に最適ではない。
いま教科書が成立しているのは、最適だからではなく、印刷と授業の都合で一本道にされていたからだ。
だから今後はこうなる。
骨格だけ共通。
経路は個別。
例も個別。
順番すら個別。
全員が同じ章立てで学ぶ時代は終わる。
だが検索だけで勉強した人間は、いつまでも断片知識の寄せ集めになる。
多くの人にとって学びやすい順序は、ほぼ決まっている。
基礎から応用。
どの分野の教科書もだいたい似た並びになるのは、人類の怠慢ではなく、人間の脳がその順でしか飲み込めないからだ。
教育は今後、その標準形を骨格として保存し、その上だけを可変にする。
未来はこうなる。
一次情報が頂点に残る。
解説はその場で生成される。
知識は共有される。
とある企業でAさんがそれを実装した”ソースコード(X)”は、多くの場合は職務著作として著作権の権利者は”とある企業”になる。
別の会社でAさんがワークフローを実装すると依拠性を満たしうる。類似したコードなら依拠性、類似性両方を満たす。かつ、Aさんはソースコード(X)の権利者ではないのでとある企業に複製権などの許諾を得る必要がある。
余談。
アイデア表現2分論てきには、ワークフロー自体は基本的にアイデア側。ソースコードが表現。（複雑かどうかはアイデアかどうかと別）（著作権的にはワークフロー自体はパックてOK.ただ不正競争防止法等の別の問題はある）
ただ、ワークフローの粒度、例えばデータ構造やDBのスキーマなど詳細になると表現と判断されうる。この境界値は最終的には裁判所ガチャ。
もっとも、ワークフロー自体が表現だと判断されても、とある企業のワークフローと別の会社のワークフローは、Ａさんみたいのがかかわっていなければ独立著作として問題ない。
そのうえでとある企業のコードを知っているＡさんが別の会社でも実装すると先と同じ結論になる。
余談2。
職務著作ではなくソースコード(X)の権利者がAさんの場合(著作権の譲渡契約などしていない)、別の企業で実装しても自身が権利者の為問題はなくなる。
しかし、職務著作でない場合でもとある企業のワークフローがアイデアで無く表現と判断されるレベルの場合、ソースコード(X)は1次著作ではなくワークフローに対する2次的著作物となる。(とある企業もソースコードXに対して原著作者として権利を有する)
結果、先と同じ問題が起きうる。
問われうる、著作権裁判を起こされる可能性があるであって、著作権侵害であるとは限らない。
スタイルはアイデアに属して、プログラマの手癖(やイラストレーターの画風など)は著作権で保護されない→雰囲気が似ていてても侵害にならない。
誰が実装しても同じようなコードになるようなアイデアである→表現の幅が狭いのは侵害にならない。
その他いろいろ…
ので、実際に裁判してみるとセーフだったりすることもある。
科目履修生してる。
元増田の主張には賛同しないけど、「その講義とテキストで金取るのは大学舐めすぎでは？」っていうのはあった。講義はテキスト読んでいるだけな上にそのテキストも書く人によって粒度がバラバラ、テストも正解以外は極論ばかりでテキストを読む必要すらないみたいな。まあ現実の大学でもやる気ない教授とかはいたけどあそこまで酷いのは見たことがない。正直金返せって思った。テキストは在校してなくても買えるからテキストだけ買えばよかったわ。もちろんいい授業もあるんだけど。
ある主婦が作成したという1日のタイムテーブルを見た。睡眠時間がわずか3時間で、息をつく暇もないほど家事や家族の世話に追われている過酷な内容だ。
ただ、タスクの粒度や内容を冷静にチェックしてみると、「毎日やること」と「週単位・月単位でやること」の区別がついておらず、1週間に実施している作業をすべて1日に詰め込んでいるように見える。
全体的な分析と指摘点は以下の通り。
以下、タスクを集約したタイムテーブルに、それぞれの視点からのツッコミ（※）を入れてみた。
※指摘: トイレや風呂場の徹底掃除（手洗いなど）を毎日行っているなら過剰。また、シーツと枕カバーを毎日洗濯・交換する必要があるのか疑問。数日に1回、あるいは週末のタスクで十分なはず。
※指摘: 冷蔵庫の掃除、窓とサッシの拭き掃除は明らかに毎日やる必要のない過剰タスク。家計簿のチェックや献立の検討も、週に1〜2回まとめて行うことで効率化できる。
※指摘: 食器棚や家電の拭き掃除、夫の靴磨きを毎日しっかりやる必要はなく、完璧主義に陥っているように見える。家計簿の記帳も毎日の必須タスクではない。
※指摘: 町内会の活動や会合は毎日あるものではない。また、夫のワイシャツのアイロンがけは、形態安定（ノンアイロン）シャツを導入するなどの工夫でまるごと省ける余地がある。
このように整理してみると、本人の「やらなければならない」という思い込みや完璧主義によって自ら首を絞めている部分と、不定期タスクを「いつものこと」として合算してしまっている部分が大きいように思える。本当に必要な「日次の家事」だけに絞れば、もっと人間らしい生活が送れるはずだ。
同じエージェントに2回登録したら全然違いすぎた。つく担当者によってこんなに違うのか。
一度目、というか他のエージェントに関してもだけど特に担当者がサポートしてくれることはなかった。最初に30分くらいヒアリングの時間があった後は面接の日程調整、合否の連絡くらい。オファー面談の段階になって初めて芯食った話ができた。でもそれで特に不満はなくて、求職者側と企業側それぞれに担当者がつくシステムなんだね、としか思ってなかった。同じエージェントに登録しなおしたのもその辺の良し悪しは一切関係なく、希望業界・職種の求人案件を得意としてるエージェントだったからってだけ。
なんというか、とにかく話が噛み合わない。
こちらの話がAの中で勝手に書き換えられるのか、Aにとっての成功パターンみたいなのに嵌め込もうとしてくるのか、こちらの要望や結論を勝手に変えてくる。
たとえば、
A「昇進したいですか？」
増田「いやまったくしたくないわけではありませんがキャリアプランの優先度的には」
増田「仮にその方向で考えるとしたら、そうですね年齢もあるのでまぁ4〜5年後とか」
こんな感じ。誘導尋問だろ。
かと思いきや面接対策とか終了後のヒアリングは完全にテンプレートそのまま。フィードバックもテンプレのコピペに企業からのコメントコピペしただけ。
これなら全部テンプレそのままで日程調整だけしてくれた方がまだマシだよと思って思い切って担当者変更希望を出した。
そしたら変更後の担当者Bがめちゃくちゃやり手。
まず、明らかにメッセージの粒度が変わった。面接対策も通り一遍のコピペじゃなく、求人票だけじゃわからない各企業ごとの情報や背景をしっかり教えてくれるようになったし、「これは面接で直接尋ねた方がいい」「この質問は面接で聞くと印象下がるもしれないからエージェント側で探りを入れる」みたいな腹芸もやってくれる。
面接不通過だったら形だけじゃないちゃんとした面接対策の時間取ってくれるし、きちんとこちらの経緯や能力をヒアリングした上でその内容をキャリアシートに反映してもいいか？とお伺いをたててくれる。Aのときにキャリアシートに合意のない記載を足されたけど、Bなら下手なことは書かないだろうと快諾した。
もしかしたらこれが普通というか本来想定されてたエージェントの形なのか？と衝撃を受けてる。別にエージェントに特別期待なんてしてなかったけど、今まで登録したことのある会社はなんだったんだ？
特定の会社が良い悪いではなく、担当者の当たり外れによるところが大きいのだと痛感した。担当者を変えてほしいと依頼するのもクレーマーみたいで正直気が引けたし、そういう経緯があったからこそ有能な人がアサインされたのかな？と思わなくもないから手放しにおすすめできるやり方ではないが、今回の担当者変更依頼はかけて正解だったと思う。
20代。特定の政党は支援してない。強いて言えば議席数に適度な競争性がある事を望んでいる。
それまで、既存の野党のほとんどは、与党をやっつけることを目的にしていた（ように少なくともメディアを通じて感じ取れていた）。
裏金問題だか森友学園だかといったスキャンダルを持ち出しては与党の印象を悪くし、ダメージを与えよう、という雰囲気に見て取れた。
確かに不祥事があるならそれは良くない事で、一定の制裁は受けて然りだ。だが、与党のスキャンダル追及で国民の生活が良くなるかっていうと、少なくとも直接的にはそうではない。
政権を奪いたい野党のオッサンはそれを酷く罵り、与党の地位を守りたい現与党のオッサンは適当にそれを逃れようとのらりくらり躱す。
しかし若者の大半は、「特定の〇〇党に勝ってほしい」というよりは、「その時国民の為になってくれる方なら柔軟に選択する」という浮動層だ。
つまり連日報道されるジジイ同士の言い争いでどっちが勝つかなんてまるで興味が無い。
でも、本人たちはそこが解ってない。
そもそも、若年層には争い事を好まない風潮がある。
細かなハラスメント教育の中で育った。強い言葉を使う奴が悪だと教えられた。
例えどんなに内容そのものが優秀でも、言い方がハラスメントじみていれば、そいつは常識知らずという「論外」のタグが貼られ、まず聞き耳を持つスタートラインに立たない。
一旦、この是非については論じないが、ただ「今の所、若者層の価値観はそれがスタンダードである」という事実がある。
それでいて、政治家の殆どが、まずスタートラインに立ってない気がする。
人が喋ってる最中にヤジを飛ばす奴。論外。
口だけで行動が伴わない不誠実な奴。論外。
結局、こういう「論外」を除いた後に残る政治家に人気が集中しているっていうのが今の現状なんじゃないかなと思う。
逆に「自民との喧嘩に躍起になってた立憲民主党＋構図的に自民に逆襲する形になり、しかも宗教関連の公明党」と「いかにも喧嘩腰で怖そうな字面の政党」と悪い要素が詰まった中道は惨敗。
「なんか怖そうで嫌」と言う印象を与えた時点でもうまず話を聞いてすらもらえないんだよ。仮に内容で凄い良い事を言ってたとしても。
でも「論外ライン」は上回って貰わないと中身を知る気にならないっていう、その層が大分かなり厚いのに計算に入ってない、そろそろ入れろ。スタンダードとして全政治家が入れろ。そこの粒度が揃ってやっと純粋な中身で選ばれるようになるのに。
選挙マッチングという仕組みは、一見すると民主主義の効率化装置に見える。
質問に答えれば、自分と政策的に近い政党や候補者がランキングされる。
政治を知らない人にとっては入口になり、情報格差を縮める便利ツールにも思える。
選挙マッチングとは、政策選好の測定装置ではなく、選好の生成装置である。
測っているように見えて、実際には作っている。
つまりこれは、統計的インターフェースを装った政治的誘導であり、より正確に言えば工作のためのプラットフォームになり得る。
工作という言葉を聞くと、多くの人は陰謀論を連想して思考停止する。
単に他者の意思決定を、自分に有利な方向へ動かすための設計を意味する。
広告も、マーケティングも、SNSアルゴリズムも、すべて工作である。
そして政治は消費よりも致命的だ。
つまり、政治における工作は、単なる情報操作ではなく、社会の支配構造を設計する行為になる。
しかしマッチングは、質問項目を通じて意見を低次元のベクトルに圧縮する。
ここで何が起きるか。圧縮とは情報の破壊であり、破壊される情報は設計者が選べる。
つまりマッチングは「この国の政治はこの論点でできている」というフレームを強制する装置になる。
政治とは本質的に「何を議題にするか」のゲームであり、「どう答えるか」は二次的だ。
しかも選挙マッチングは、その世界観を「中立な診断テスト」の形で提示する。
中立に見えることが最大の武器だ。これは医療診断の権威を政治に転用した詐術に近い。
人間は「あなたはこのタイプです」と言われると、それを自己理解として内面化する傾向がある。
つまりマッチング結果は、単なる推薦ではなく、アイデンティティの付与になる。
たとえば「格差を是正するために富裕層への課税を強化すべきだ」という問いは、一見公平に見えるが、すでに「格差は是正されるべきである」「富裕層課税は是正の手段である」という価値前提を埋め込んでいる。
問いは中立な容器ではない。問い自体が論理式であり、前提を含む。言語は常に誘導する。質問を作るとは、政治的現実の記述ではなく、政治的現実の編集である。
ここで「いや、回答者が自由に答えればいいだけだ」と言う人がいる。
しかしその反論は、情報理論的に幼稚である。人間の意見は、質問形式に依存して変化する。
フレーミング効果、アンカリング、選択肢の提示順序、否定形の有無、尺度の粒度。
つまりマッチングは、ユーザーの「元々の意見」を測定しているのではなく、質問に曝された後の「変形された意見」を測っている。
しかもマッチングは、最終的に「あなたはこの政党と一致度85%」のような数値を出す。
ここで人間は数値に弱い。数値が出た瞬間、それは客観的事実のように見える。
だがその85%は、設計者が定義した距離関数の結果でしかない。重み付けを変えれば順位は変わる。
質問の重要度を均等にするのか、特定争点を強調するのか。政策一致をコサイン類似度で測るのか、ユークリッド距離で測るのか。曖昧回答をどう扱うのか。未回答をどう補完するのか。
これらの選択は数学の衣を着た政治判断である。数値は政治的意思決定の上に乗っているだけで、政治判断を消し去ってはいない。
選挙マッチングが工作になる第二の理由は、二値化による思考破壊だ。
政治的問題の多くはトレードオフである。たとえば防衛費増額は安全保障を強めるが財政を圧迫する。
移民受け入れは労働供給を増やすが社会統合コストを伴う。規制緩和は成長を促すが安全性を下げる場合がある。
現実の政治判断は、複数の目的関数の同時最適化であり、パレートフロンティアの上での選択である。
ところがマッチングは、これを「賛成か反対か」の単純なビット列に変換する。
つまり政策を理解する能力ではなく、反射神経を測るテストになる。こうして政治が「道徳クイズ」へ堕落する。
利害調整、官僚機構の制御、外交交渉、予算編成、法案作成、危機対応。政策は宣言であり、実務は別物だ。
マッチングはこの現実を完全に無視し、「政策の一致度」という最も分かりやすい幻想だけを見せる。
これは、料理を評価するのにレシピだけを見て、調理人の腕も厨房の設備も無視するようなものだ。
ランキングは、人間の意思決定を強制する。上位にあるものは正しい気がする。これは認知心理学のヒューリスティックであり、探索コストを減らすために人間が採用する合理的なバイアスだ。
マッチングはこのバイアスを利用し、ユーザーの投票行動を数候補への収束に導く。
これが何を意味するか。選挙マッチングは、選挙市場における需要の誘導装置になる。検索エンジンの上位表示が商業を支配するのと同じ構造が、民主主義に侵入する。
そして最も危険なのは、マッチングの背後にある主体が不透明な点だ。
誰が運営しているのか。資金源は何か。質問は誰が決めたのか。政党の回答はどのように取得し、検証し、更新しているのか。候補者が嘘をついた場合にどう扱うのか。アルゴリズムは公開されているのか。重み付けは固定か。ユーザー属性に応じて変わるのか。
これらがブラックボックスなら、それは政治的レコメンドエンジンであり、事実上の選挙介入である。
しかもSNSのように露骨ではない。教育的ツールを装っている分、遥かに強い。
重要なのは機能である。システムが特定方向への誘導を内蔵しているなら、それは工作機械である。
旋盤が意図的に金属を削っているかどうかなど問題ではない。削る機能があるから旋盤なのだ。
同様に、選挙マッチングは意見を削り、争点を削り、候補者を削り、最終的に投票行動を削り出す。これは政治のCNC加工機である。
もしユーザーの回答履歴が蓄積されれば、政治的クラスタリングが可能になる。年齢、地域、職業、関心領域、回答パターンから、政治的嗜好の潜在変数が推定できる。
これは推薦システムの典型的応用であり、NetflixやAmazonがやっていることと同じだ。
すると次に起きるのは、パーソナライズされた政治誘導である。あるユーザーには経済政策を前面に出し、別のユーザーには治安を前面に出す。質問の順番を変え、回答を誘導し、結果を最適化する。
つまり「あなたの性格に合わせた政治プロパガンダ」が自動生成される。これはもう民主主義ではなく、行動制御の最適化問題である。
ここで反論が出る。「それでも政治に無関心な層が投票に行くならプラスでは？」。
だがこの反論は、民主主義を単なる投票率競争に矮小化している。
無関心層を動かすこと自体が善なのではない。どう動かすかが本質だ。
誘導された意思決定は、意思決定ではなく条件反射である。民主主義は、条件反射の総和を集計するための制度ではない。少なくとも理念上は。
選挙マッチングの最大の罪は、「政治とは何か」という理解を誤らせる点にある。
政治は、単なる政策の一致ゲームではない。政治とは、価値観の衝突を制度の中に封じ込め、暴力なしで調整する技術である。
さらに言えば、政治は時間軸を含む。短期の人気政策と長期の持続可能性は対立する。
インフレ抑制と景気刺激は対立する。社会保障の拡充と財政規律は対立する。現実は多目的最適化であり、単一の正解はない。
ところがマッチングは「あなたの正解」を提示してしまう。この瞬間、政治は宗教化する。正解があると思った人間は、対話をやめ、敵を作り、道徳で殴り始める。
そして皮肉なことに、選挙マッチングは中立ツールを装うことで、政治的責任を回避する。
推薦した結果が社会を破壊しても、運営者は「我々はただの情報提供をしただけ」と言える。
しかしそれは、銃を売った者が「撃ったのはあなた」と言うのに似ている。形式的には正しいが、本質的には責任逃れである。推薦とは介入である。介入は責任を伴う。
選挙マッチングは、政治の理解を深める装置ではなく、政治の複雑性を圧縮し、認知バイアスを利用し、意思決定を誘導する装置である。
ゆえにそれは工作である。工作とは「誰かが裏で悪意を持って操っている」という陰謀の話ではない。設計された情報環境が、個人の選択を体系的に変形するという、構造の話だ。
そして現代社会において最も危険な工作とは、強制ではなく、便利さとして提供される。
人は鎖で縛られるより、最適化されることを好む。摩擦のない誘導は、抵抗されない。選挙マッチングが普及すればするほど、人々は自分の政治的意見を「診断結果」として受け入れるようになる。
そうなったとき民主主義は、熟議ではなくレコメンドによって動く。これは政治の消費化であり、最終的には政治そのものの死である。
CLAUDE.md や rules / skills みたいな形で、重要なコーディングルールはあらかじめかなり固めておく。
たとえば repository 層や Entity 層は具体的にどう書くのか、テストケースはどういう書き方をして、どういう観点で項目を洗い出すのか、みたいな AI への指示は最初から用意しておく。
あと、linter や ArchUnit、dependency-cruiser みたいなアーキテクチャ制約も、自分なりの定石を持っておく。
割と過剰なレベルでガチガチに固める感じで、アーキテクチャルールも「◯◯は XXX に依存できない」みたいなブラックリスト式じゃなくて、「◯◯は XXX だけに依存できる」みたいなホワイトリスト式の方が良いと思っている。
ts 前提だと eslint や tsconfig は一番厳しい水準に設定する、流石にきつい部分でてきたらそこだけ緩める、という運用
おすすめなのは、何かしらの小規模案件や個人開発アプリを1つオーバーエンジニアリング上等でガチガチ構成で作っておく。
そこで出てきた linter 設定やプロンプト設定を、別案件に横展開する感じ。
正直、ガチガチすぎると MVP とかレベルだとコード量は増えるけど、メンテする前提の案件ならバイブコーディング時代だと普通にペイすると感じている。
アイディアを思いついたら、AI と壁打ちしながら仕様を洗い出していく。
手書きでドメイン図を書いて、それを写メ撮って画像認識で仕様整理、みたいなのも割とアリだと思っている。
どういう画面があって、どういう入力項目や表示項目が存在するか、バックエンドはどういうエンドポイントが必要か、この辺りは最初に一通り洗い出しておく。
それに加えて、ユーザーが初めてトップページを開いてから登録・ログインして実際にサービスを一通り使うまで、みたいな流れをそのまま Playwright のシナリオテストに落とせそうな形で何パターンか仕様書にしておく。
フロントエンドで、DDD における集約みたいな概念がそのまま当てはまらない領域についても、設計時点で洗い出せているなら Entity 的なものやドメインサービス的なロジック用のレイヤを作って、ドメインオブジェクトとして実装していく。
最初に作った基本設計をベースに、◯◯Entity、XXEntity、△△Entity……を作るためのプランとチェックリスト形式の TODO を 1つの md ファイルに吐き出してもらう。
フェーズごとにフォーマッタ、linter、アーキテクチャルールなど一括実行したコマンド実行させて失敗してたら成功するまで修正繰り返させる。
ある程度わかりやすい単位で AI に依頼する感じで、出来上がったコードをレビューする前提なので、実装プランの md 自体はよほど分かりやすいツッコミどころがない限り細かくレビューしない。
mdのフォーマットは skills 側で事前に用意しておく。
フロントエンド用、バックエンド用の両方でドメイン層のファイルを作る。
当然、足りないロジックは後から絶対に出てくるけど、最初から完璧は目指さない。
TODO 一覧の中から自分の認知負荷が許す単位で「チェックリストのここからここまで実装して」と指示を出し、実装が終わったら TODO 項目のチェック状態を更新してもらう、mdファイルもコミットに含める。
コミット前にはlint ルールを無効化していないか、意図通りの実装になっているかは git diff の差分で必ず確認する。
git worktree を使うことが多い。
よくやるのはフロントエンドの画面モック作成とバックエンド実装の2並列で行う。
実装プランを考えてもらうときは「◯◯画面を実装プラン考えて」くらいの単位で依頼する。
実装プランの md ファイルを作るときのプロンプトには、基本設計の〇〇画面の項目一覧をベースに、◯◯のアイテムコンポーネント、リストコンポーネント、◯◯のボタンコンポーネント、Information コンポーネント、外部通信用の ◯◯Gateway を実装する、◯◯コンポーネントは既に ◯◯ 機能で実装してあるからそれを使って、◯◯は処理が膨らみそうだからドメインサービスで実装して、みたいな感じで頭の中のふんわりしたイメージを伝える。
バックエンドも同様で、◯◯のエンドポイントを作って、Gateway がこれこれ必要だから実装して、これはインターフェースと実装分けてね、Entityへの変換処理は関数分けて、◯◯の処理は Usecase 層で、◯◯の処理はドメイン層で、Usecase が膨らみそうだから ◯◯ の処理は独立したクラスにして、あ、似たようなのが ◯◯ 機能にあるからそれを参考にして、くらいの粒度で指示を出す。
フロントエンドの実装を待っている間に、バックエンドのプランを考えたり、タスク粒度を調整したり、リファクタリングプランを考えたりする、またバックエンドのAI待ち時間はフロントエンドのことをする。
フロントエンドオンリーの実装とかで作業が競合するリスクあるときは並列作業しない。
チェックリスト更新が終わるごとに差分を確認して、問題なければコミットメッセージを提案してもらってコミットする。
細切れにするコストよりも、レビューする人間の認知不可が許すレベルであればある程度まとまった単位でレビューして実装速度を優先する派。
テストは、ある程度実装が進んでリファクタリングが辛くなってきたタイミングで作ることが多い。
カバレッジやミューテーションテストなど、定量的にテストを評価できる仕組みは導入する。
バックエンド側のテスト実装は正直かなり楽で、行数や認知的複雑度を厳しく制限して単一責務の原則を守って実装しておけば、AI がかなり高精度なテストを出してくれる。
これもテストファイル実装プランを作ってもらって「ここからここまでのテスト20ファイルを実装してね」をレビュー挟んで繰り返す感じ、例えばミューテーションテストのkill率100%ならそんなに詳しくは見ない。
フロントエンドはテストの定量指標での評価が難しいので、そこはその分レビューを頑張るしかない。
自分はこんな感じでやっている。
感覚としては、優秀だけどシステムのアーキテクチャ全体の責務を負ったことはない経験不足の2年目やSESの部下を扱うEMに近いのかなぁ。
周りの話を聞いていると、もっともっと AI に自律的にいろいろやらせているようにも聞こえる。
これでも 1日1人で数万行レベルはコードを書けてるので、AIない時代に比べると数ヶ月分の成果を1日とかで出してることになるが、もっと本気出せるのかなぁ。
「全機能分プラン作ってね！そこから良い感じの粒度でコミットも自分でやってね！」みたいな指示を良い感じに出せたとしても、指示がでかすぎると、脆弱性盛々になったり、lint エラーループでパニクって linter オフにし始めたり、テスト通すためにエラー握りつぶして assertTrue(true) し始めたりする。
それは流石に許容できないレベルじゃない？が紛れ込むリスクが上がりすぎるんじゃないかなぁ。と思ってるんだがどうだろうか。。。
あとツールはあんま入れてないねkiroとかspec-kitとか、ガチガチ細切れで仕様書作るメリットもあんま感じなかった。
mcpもserenaくらいしかいれてないや、トークン節約してレートリミットの猶予伸ばした方が結局開発早くなるかなって。
いろいろ入れた方がいいんだろうか。
完全にオレオレでこんな感じでやっているんだけど、みんなspec駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
機能追加とか特定機能の開発のときに出てくる一時的な steering ファイルみたいなのはイメージしやすいんだけどさ、
単一責務とかレイヤードアーキテクチャをちゃんと意識して実装して、
仕様書を書くとしても、tsdoc や javadoc じゃダメなのか？
小規模ならまだしも、100万行規模のシステムで実装内容を全部自然言語に落としたドキュメントを維持するの、正直結構辛くない？
コーディング方針とか設計思想ならCLOUD.md とか skills で十分な気もするし……
きっと頑張り屋な君のことなので、今日もこっそり仕事をしていたり、仕事のことを考えていたりするのでしょう。
休む時は、休む。休んでまた元気に頑張る。
さて、本当に私が伝えたいのは、そんなことではありません。
弊社で働く上で必要な情報のキャッチアップができていた、ということもありますが、新卒一年目とは思えないほど、ずっと優秀だと思いました。
的確に意見を述べ、業務を推進していく姿は本当に立派ですし、学生の頃からの姿を見ていることもあり、君の成長ぶりにはなんだかしみじみとしてしまうこともあります。
比べるのもおこがましいくらいに、私が一年目の時よりもはるかに頑張っているし、良い経験ができている。とても羨ましいです。
きっと、君自身も自分は仕事ができると自信を持ち始めている、いや、自信を持っていますね。
自信があるのは素晴らしいことです。自信がなくても多少自信があるように見せる、ということも社会人として必要な姿勢ですしね。
さて、そんな君に少し今年を振り返って考えてみてほしいことがあります（休んでね、という話をしたばかりで申し訳ない）。
仕事というものは、当然ですが一人では進められないので、今年一年、いろんな場面で、いろんな人に質問、相談、依頼をしましたね。
多くの人に助けられたなあ、という気持ちにもなっているのではないかと思います。
もちろん、弊社の人間は心優しく、仕事のできる人ばかりなので、率先して手を差し伸べてくれたでしょう。
勝手ながら、少しでも、何かが君の心をよぎっていたらいいなと思っています。
ここまで遠回しなことばかり言ってしまったので、疲れさせてしまったかもしれません。
今の君の仕事の進め方、先輩たちへの質問、相談、依頼の仕方では、いずれ君が困ることになるかもしれません。
失礼、まだまだ遠回しすぎました。
君は、先輩たちへのリスペクトが欠けているように見えています。
あくまで、「ように」「見えている」のですが、内心で思っていることは、本人の自覚があろうとなかろうと、他人には分かってしまうものです。
先輩たちについついタメ口で話していませんか？
自分のタスク管理の問題でスケジュールが逼迫しているときに、代わりの依頼を無言でカレンダーに入れていませんか？
依頼の仕方が雑になっていませんか？背景や必要な対応の粒度を伝えないまま、ただただやってくださいになっていませんか？
君より後に入った中途入社の人に、君が十分にレクチャーしていないことが原因にもかかわらず、なぜ自分に先に聞いてくれないのか、と言い放ったことはありませんか？
あ、少し心当たりがあるようですね。それはよかった。記憶がないと言われたら、そこまでですから。
なんでお前がそんなことを知っているんだって？
誰がどんな対応をしているか、は耳に入ってくるものですし、私は結構見ているんですよ…意外ですか？
これは私の勝手な予想なのですが、きっと、君の持つ自信が、そうさせてしまっているところもあるのかもしれない、とも思います。
そして、それは私たち先輩社員のせいでもある、とも強く感じています。
君が学生の頃から一緒に働いている仲だからこそ、私が一番に、伝えなければなりませんね。
でも、言えなかった。
今年のうちに、ができなかった。
君のためを思っているなら、やるべきことが、できていない、こんな先輩でごめんなさい。
来年は絶対に伝えよう、と誓っているのですが、もし、君がこの投稿を目にして、自分のことかも、と思ったのなら。
どうか、君が周りの人から信頼され、何かあったときに、新卒という身分も消え去ってしまったときでも、この人なら助けたい、と思われ、手を差し伸べられ続けられる存在でありますように。
そう願ってやみません。
下手すると40〜50代から終活やってる人もいるけど、正直アホかと思う。
正気とは思えない。
終活に関わっている人間で、「終活とは何か」をはっきり説明できるのは、高齢者と日常的に関わっていて、かつ相談業務を担っている人間だけだ。
具体的には、病院のメディカルソーシャルワーカー、介護施設の相談員、役所のケースワーカー。
話が逸れた。終活とは何か、という定義は一旦置いておく。ここではまず、「意味のない終活」と「意味のある終活」を並べてみる。
・墓や骨に関する希望を考える
・献体
・既往歴、飲んでいる薬、かかっている病院等をまとめる
・親族と死後のことについて話し合う
どうだろう。
共通点も薄いし、粒度もバラバラなものが並んでいるように見えるかもしれない。
じゃあ改めて考えてほしい。終活は何のためにやるのか。
「自分が納得のいく死に方をするため」？
違う。
人はそう簡単に死なない。
まず慢性疾患になる。全身が痛くなり、動くのもしんどくなる。
だんだん認知機能が落ち、場合によっては入退院を繰り返し、介護保険サービスを使うようになる。
この過程で、自分自身の客観的な情報が整理されていないと、本当に詰む。
一生懸命、葬儀のやり方を考えておくことなんて、死に近づく過程では一ミリも役に立たない。
実際に死んだあと、戸籍と財産の全体像が分かっていると、親族はめちゃくちゃ楽だ。
これが分からない、しかも親族間で揉める、となると年単位の泥沼が始まる。
「葬儀なんてしなくていい！献体してくれ！」じゃなくて、お前の口座を全部リストアップして、冷蔵庫に入れておいてくれ、という話だ。
特に「誰が」「何を」やるのかを、自分のケースに置き換えて考えてほしい。
それが終活だ。
死ぬ側が一方的なホスピタリティを期待して、わがままを叫ぶことではない。
特に「迷惑をかけたくない」「できるだけお金をかけたくない」は、元気なうちによく言いがちな戯言だ。
迷惑はかかる。
認知症になれば、排泄が一人でできなくなれば、倒れたら、必ず誰かの手が必要になる。
多くの人は、自分は死ぬまで元気で、最後はぽっくり死ねるという誇大妄想を抱いている。
さて、ここまであえて触れずにきたが、終活において「しっかり動いてくれる親族がいるか」は、最重要ファクターだ。
いるなら、その親族と積極的に関係を作っておくことが一番大事。
「迷惑をかけたくない」と言って連絡も取らない、なんて愚策は論外だ。
一方で、そうした支援者がいない人はどうするか。
要するに「死後事務」を誰にどう任せるかという話だ。
依頼する相手は、「自分が85歳のとき、相手は何歳か」を必ず考えること。
親族もいない、金もないなら、行政の支援を積極的に使うしかない。
具体的には、地域包括支援センターと関係性を作ること。
国も本当は、これくらいはっきり言いたいはずだ。
ただ、「しっかりした子どもがいるかどうか」で話を分けるわけにもいかないし、墓探しからでも興味を持ってもらえる方が都合がいい。
衰えるほどに人と関わること。
終活は、それだけでいい。
推薦システムを作ってると、ふと機械学習って本当に必要か？と疑問に思う瞬間がある。
たとえばユーザーをいくつかのグループに分けるだろう。そして各グループがどんな属性のアイテムをクリックするのかを見ていく。
すると、実はそのクリック分布を眺めるだけで、ユーザーの行動領域なんてほぼ特定できてしまうんだよな。
つまり、ユーザー×アイテムの関係性は、結局データベースの設計レベルで決まってしまう。
結合の仕方や属性の粒度をどう設計するかのほうが支配的で、クリック履歴をわざわざ機械学習モデルに食わせて学習させる意味は、想像以上に小さい。
仮に機械学習が役立つとすれば、それはユーザーやアイテムの未知属性を推定するような補完的な部分だけなんだよ。
たとえば年齢層が不明なユーザーに対して、クリック傾向から年代を推測するとか、アイテムの特徴を自動抽出するとか。
けどそれは、推薦の核心ではない。推薦の本質はクリックさせることにある。
そしてその瞬間、重要なのはアルゴリズムじゃなく、デザインや文言、つまり心理的なトリガーなんだ。ボタンの色ひとつ、コピーの一文ひとつでCTRなんて平気で変わる。
クリック率を上げるって話になると、もはやエンジニアリングの領域じゃなくて心理設計の領域なんだよ。
だからプログラマーの俺がどれだけアルゴリズムを磨いたところで、根本的な改善にはならない。
A/Bテストで調整する手もあるけど、それも何度も繰り返せばユーザーは離脱する。
つまり、理屈の上でどんなに精巧なモデルを作っても、現実の行動を左右するのは心の動きであって、数式じゃない。
そう思うと、機械学習の出番って案外、思われてるよりもずっと狭いんだよな。
プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…！」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。
近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。
開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のものが出回っている。Eclipseとか今考えるとよくあんなので開発できてたな。
いまや小学生からおばあちゃんまでアプリ作りに熱中し、高校生はIoTとかやり始め、大学生は商業レベルか？ってレベルのものをネットで発表し、私はウェブアプリのスマホでのレイアウト崩れひとつすら直せず静かにエディタを閉じてnoteで過激タイトル記事を書いている。
掛け算に順序があると思っているような知能の下級雑用係（自分のことを教育専門職だと思い込んでいる）ですら「小学生にプログラミングを教えるぞ！」と意気込んでいる。やめろ。お前らには無理だ。無理だからマジでやめろ。考え直せ。無理だって。掛け算に順序つけないと相手に教えられないレベルのやつがプログラミング教えるのマジで無理だって。算数とは次元が違うって。「ピーチ姫いつも簡単に誘拐できるし今度はベヨネッタも誘拐してみるか」ぐらいの無謀さだって。やめとけ。マジでやめろ。
まあそんなこんなで入り口はめちゃくちゃ広く、入門するのはマリオカートより簡単である。話逸れるけどSwitchのマリオカート、運転アシスト機能ついて初心者でもコース完走できるようになったから心折れちゃった人ももう一度チャレンジしてみてね。
それとは特に関係ないんだけど、大学行ってた時ティーチングアシスタント（TA）っていう授業のお手伝いさせられたのよね。ちゃんとお金出るやつ。
学部の3年か4年から始まって、院の1年か2年までやってて、途中で休学挟んだから、ええと、あー、うん、数年間TAやってたんよ。数学とプログラミングのコマ。CとOctaveとかいうやつ。Cのほうは情報学科で、Octaveは違う学科。JavaとかC++のコマはTA入れさせてもらえなかった。
プログラミングの実習は週2コマ（連続）あって、情報学科なら必修科目。なのでサポートは相当手厚く、先生とTAが絶え間なく机間巡視し、わからないことがあればセンパイがなんでも答えてくれるというわけだ。授業外でもサポートはしており、わからなければ先生や研究室にいる学生に好きなだけ聞きにいっても良いということになっていた。必修だから落とされたら困るしな。
2コマだから3時間 * 15回で、45時間。そして私の時は2年まででC/C++/Javaと必修だった（今はなんの言語かは知らない）ので、その3倍、135時間は最低やることになる。プログラミング実習以外にもプログラミング触る授業多いから実際はもっと多い。宿題やる時間もあるので実際はもっともっと長くプログラミングに触れることになる。卒論書く時期に入ると、テーマによっては書く人はさらに書くので、もっともっともっともっと長い。
これだけ時間をかければほとんどの人がプログラミングできるように……ならない。むしろできない人の方が多い。なんで。why。教えて。
会社になるとさすがにプログラミングできるできないは死活問題である。
「今日から入ったxxでーす。業界未経験ですがよろしくおねがしまーす。さっそくなんですけどPythonのここわかんないんですけどどうすれば……あっそうすればいいんですね。次はここなんですけど……なるほど！ありがとうございます。じゃあまた明日ー」
いやー社会人にもなると熱意が違うね。学生なんかわかんなくてもほとんど聞きに来ないのにな。こりゃガンガン伸びますわ。私も社会人1年生でPythonなんて3秒ぐらいしか触ったことないから適当答えてるけど。
「ちょっとお時間よろしいですか？」「いやちょっと今忙しいから後になっちゃいますわ。すんません……」
そんなこんなで1週間ぐらい放置してしまった。やべー絶対嫌われる。どこまで進んだかな……？えっまだそこ？進んでなくない？
もしかしてこれ全部教えないとダメなやつか。そりゃ大学4年間プログラミングやったやつでもプログラミングできないんだから、そうか。よく考えると当たり前だよな。
プログラミングをやめろ
大学4年間と大学院2年間プログラミングやったやつでもできないし、会社で毎日8時間を数週間プログラミングについやしてもできないやつはできないし、そもそも人類というのはプログラミングできない可能性がある。
少年少女たちに「プログラミングはいいぞ！自由にものが作れて達成感がある！頭が良くなった気分にもなれるし！」と吹聴してまわんのもいいけど、6年間情報科学について勉強したようなやつの大半がプログラミングできないんですよ。それもごくごく初歩的な部分。
野球とかサッカーなら、まあ友達との試合には参加できなくてもごく稀にバットにボールを当てたり、ボールを1回あらぬ方向に蹴ったり、ぶっちゃけ周りとのレベル差で楽しくなくてすぐやめちゃうだろうけど、なんとか基礎の一部ぐらいはできるじゃないですか。
ピアノとかダンスでも、猫踏んじゃったをごくごくゆっくり弾くぐらいはできるかもしんないし、学芸会の振り付けを10秒ぐらいは踊れたりできるかもしれない。その後やっぱ周りのレベル見て諦めちゃうかもしんないけどさ。
プログラミング、6年やってミットを頭にかぶってるバッターとか、鍵盤蓋の上から殴って音鳴らそうとするやつとか、まずそういうレベルのやつが大量発生するんですよ。だいたい7割ぐらいの率。どうすんだよこいつら。私の教育の問題か？マジで？本当に？
プロが練って考えて凝縮した本や授業、センパイたちによる指導。それらを結集して得られるはずのものが7割ぐらいどっかに消し飛んでる。無駄だろこれ。
今からプログラミングやろうとしてるやつ、お前は確実に向いてないからさっさと諦めて刺身にタンポポ乗せる仕事に戻ってくれ。参加しても鍵盤蓋叩き割るやつと同じ病室に入るだけだ。
プログラミングをやめろ。
ぼくはこう思うんですよ
そもそもなんで大の大人がそんな両手にバット持ってセカンドに立ったりゴールの方をボールのところまで動かす奇行に走るんだろうな。わかんねえや。
綺麗な分析はできないけど、いわゆる「できない」やつが共通して言ってたフレーズがある。
「ぼくはxxxだと思ってるんですけど、動かないんですよ」
うん、そうだね。そう思うんだ。でも動いてないじゃん。じゃあ違うんじゃない？モニターに「にらみつける」やってもバグは取れないし防御力下がるだけだぞ。
まず根本的に考えと事実が違ってるって結果出てるじゃん。じゃあもう考え変えちゃえば早くない？
名言の引用は好きではないけど、「プログラムは思った通りには動かない。書いた通りに動く」って言葉がある。実に名言だと思う。次点で好きなのが「ある問題を解決しようと正規表現を使うと問題が2つに増える」かな。
お前が何を思っているかはプログラミングにおいて一切影響しないんだよ。お前が何を書いて、コンピュータがどう処理したか、それが全て。
深く考えないことについてぎゃーぎゃーいうやつもいるけどプログラムなんてまず最初は動けばいいんだから何も考えずに次試せばいいだろ。んで3回ぐらいは自分で思い浮かんだの試して、全部ダメだったら調べるとか先生に聞いてみるとかさ。逆に1発で通ったら自分の思考見直して理解深めるとかさ。
ドキュメントとかあんまり理解できない初心者のうちは、とにかくお試しと修正のサイクル回すの重要で、「これがこうだから動くはず」というカードを3種類ぐらい作って全部片っ端から試すのが早いと思うよ。モニターをにらみつけるな。
お前がどう思ってるかよりも、まずはお前の書いたプログラムがどう動いているか（どう動いていないか）を確認するのが先だ。動かなかったら考えが違う、はい次のプラン、はいその次のプラン、はい次。
この「ぼくはこう思ってる」が出てくるの、なんの教育の成果なんだろうね。お前の気持ちなんてどうでもいいって現国でも数学で散々教えられただろ。
Error: variable 'a' is undefined, line 24
↑のエラーは架空のエラー文（英語下手でも許して）だけど、エラー、出るよね。プログラム組んでたら。んでやっぱいるのよ。エラーを「にらみつける」やつ。解決しねえって言ってんだろ。
「エラー出たんですけど、どうすればいいんですか」
「エラーにはプログラムがなぜコンパイル通らないかの原因がそのまま書かれている。例えば今出ているError: variable 'a' is undefined, line 24は、24行目の変数aが未定義ということを示している。事前に変数aを定義していないか、打ち間違えてsになっているとかではないのかな？」
だいたいが「腑に落ちねぇー」みたいな顔する。まあ、一気に喋りすぎたしな。疑問点1個1個潰していくか。
「何か疑問点ありそう？変数ってなにー、とか、定義ってなにー、とか」「ないです。わかりました！」
わかったのか。よかった。またモニターをにらみつける開始。なんでだよ！！！！「お前顔にチョコついてるぞ」って言われたらチョコ拭き取るだろ。変数aが未定義ですねって言われたら変数a定義すりゃいいだろ。
でもプログラミングド下手なやつ（全人類の7割ぐらい）は、エラーをにらみつけてる。ずっとにらみつけてる。防御力下限まで下がったかな。にらみつけてて何が変わるんだよ。
「英語読めなくて……」
いや「a is undefined」なんて「He is Superman」ぐらいの英語だろなんで読めないんだよ。お前この大学どうやって入ったんだよ。たしかどの入試方式でも英語あっただろ。単語わからんかったらググれ。
「aが未定義って書いてあるんですけど、ここのfor文の私の考えが間違ってるのでしょうか」
いや24行目のaって書いてるだろ。まずなんでそこ無視するんだよ。お前がfor文で使ってんの教科書通りのiだろ。24行目ってわかるか？for文あるの40行目あたりだよな？aとiが違う文字ってわかるか？
「さっきのエラー直したら新しいエラーが出たんですけど、どうすればいいですか」
千尋！贅沢な名だねえ
変数に名前をつけろ。関数に名前をつけろ。クラスに名前をつけろ。全てに名前をつけろ。
C言語の古い教科書だと「a」とか「b」とか「i」とかで書いてるけど、そんなの人間が読めるわけねえだろ。冷静に考えろ。「input」「output」「index」とかにしとけ。
2重for文の変数名i, jにしたら絶対途中で打ち間違えるだろ。お前は打ち間違える。そういうやつだ。2重ループなんてどうせ行列計算の課題だろ。rowとcolumnにしとけ。これで打ち間違っても気づくし、それぞれに意味が付いてくる。
ちなみに同じ長い名前にも優劣がある。「result」よりも「sum」のほうが強い。「result」はなんの結果かわからない（全ては結果であるので）が「sum」は合計値であることがわかるからだ。「password」と「plainPassword」なら「plainPassword」が勝つ。暗号化されていないパスワードであることがわかるので、情報量が多いからだ。
ただし例外はいくつかある。「tmp」は一時変数であることが（プログラマにとって）明らかだ。「dir」はディレクトリであることがわかる。「src」「dist」あたりもよく使われる。このあたりは短くていいんじゃねーかな。
でも、この前温度センサ扱うプロジェクトで「tmp」って変数名使って温度(temperature)と脳内で混線してバグって発狂してた同僚いたけど。そういうときは名前長くするか別の名前使おうな。
関数の名前なんて「calcAverageFromArray」ぐらい長くしていいから。「myFunc」とかしなくていいから。「fetchJsonDataFromUniversityInternalServer」とかでいいから。マジで。いやこれ本当に。
そもそも今時ディスプレイでかいし、識別子なんて先頭数文字打ったらエディタが補完してくれるし、短くするメリットがない。
それでも名前が長いと感じる？関数がでかすぎるんじゃないか。細かく処理を分けるとかしてみろ。「combineArrayAndFindMax」関数は「combineArray」と「findMax」に分割したらいいと思うぞ。名前が長いと思っても名前を削るな、機能を分割しろ。自然と名前が短くなる。
それかシンプルでかっこいい名前を見つける。「convertEvilHtmlToPeacefulText」は「sanitize」に置き換えることができる。イカす名前だ。
プログラミングできない奴はマジでこれらのことをやらない。ずっとaとかbとかzとか使ってる。お前それ自分で読めんのか。読めねえだろ。myfuncってなんだよ何するんだよ。お前自分で理解できてんのかそれ。
それでも頑なにaとかbとか使う。なんでだよ。
動作原理わからず書き散らすな。動作原理っつってもそんな深いところじゃなくて言語表面上レベルの動作な。
リテラルは値を作成して、代入は値に名前をつけている、とかその程度のレイヤー。メモリがどうこうとかはいらんと思う。あっでもポインタのときはいるか……。めんどくせえな。
まあ動作原理っていうか自分が何やってんのか理解してくれって程度の話になるんだが。
例えばfor文で処理50回まわすとき、「50回分の処理を行なっている」ではなく「ループ開始時に変数を初期化。条件判定して成立していれば文の中を実行する。条件変数の値を変化させてまた条件判定からやり直す」ぐらいの粒度で捉えててほしいかな、という気持ち。
これはfor文で詰まる人がやたら多かったからだ。彼らはfor文をアトミックな操作だと思っていた。つまりfor文はひとまとまりの命令であり、長いfor文とprintfの間に粒度の違いはないと思っていたらしい。
つまり、「for文の中でエラーが起こる」という事象がほぼ理解できない。forはアトミックであり、内部など見えないのだから。じゃあお前が今書いたfor文の中身はなんなんだってやんわり聞くと「さあ…？」みたいな反応が返ってくる。はあ。
関数についてもなかなか誤解が多かった。関数「sum_array(a, b)」と関数「average_three_numbers(a, b, c)」は全く別の原理で動いているのだと。ここでの「全く別の原理」というのはシグネチャが違うとか実装が異なるとかそういう意味ではなく、コーラを飲んでゲップが出る原理と糸電話で声が伝わる原理ぐらいの全くの別、という意味である。
彼らは関数ひとつひとつについて「新しく原理を学習」していたのだ。マジかよ……。どうやったらそんな発想に行き着くんだろう。そりゃ時間かかるわな。
そのため、関数が値を返す（または返さない）ということも理解できておらず、「関数の戻り値と関数の戻り値を足す」とか「関数の引数に関数の戻り値を直接渡す」とかやりだすと大パニックになる。メソッドチェーンとかやった日には大学潰れると思う。ただ、これはC言語が悪い部分もあると思う。配列とかいじりだすと、初心者が書けるレベルの関数だとあんまり値返さないしな。
たのむ、他のはできなくてもこれはできてほしい。自分が何をやりたいのかは理解してほしい。流石にお前のやりたいことなんて他人にはわからんぞ。
「配列の中の数値の合計値を求めたいんです」とか「名前と身長と体重をひとつにまとめた構造体が作りたいんです」とか。簡単なのでいいから。
「いま何やろうとしてどこで詰まってる？」って聞いても「……？」みたいな反応されたら困るんだよ。
例えば「キーボードから数値を10回入力し、それぞれの値を配列に格納して、最後に配列の値を逆順に表示せよ」みたいな問題が出てきたときに、「キーボードから値を入力する」「10回繰り返す」「配列に値を格納する」「配列の値を逆順に表示する」に分解できると思うんだけど、自分が何やりたいのかわからない奴はまずこれができない。
彼らには「キーボードカラスウチヲジュッカイニュウリョクシソレゾレヲハイレツニニュウリョクシテサイゴニハイレツノアタイヲギャクジュンニヒョウジセヨ」に見えている。
かろうじて「キーボード」「ハイレツ」あたりの単語は拾えるらしく、標準入力から値とったり配列を作ったりはしてるんだけど、そこから先に進まない。モニターにらみつけてる。またにらみつけるかよ。
あれだ、算数の文章題できなくてとにかく文章に出てくる数値足したり引いたりするやつ。あれのプログラミング版。文章が読めない。
こういう人にはメモ用紙取り出して、まず文章が何について言ってるのか、どういう工程に分けることができるのか、今後も同じことが起こったときにどうやって分けるのか。みたいなのを教えるんだけど、大抵あんまりしっくりこないらしく、成功したことは皆無。なんとかうまく教えたいんだが。
もうこのあたりになってくるとプログラミング関係なくね……？ってなるんだけど、意外とそういうプログラミング関係ないところで詰まる人めちゃくちゃ多いよ。
今すぐプログラミングをやめろ
辞める少し前に外務省の垢で使える執務用AIが導入されたんで、休憩時間や勤務外の時間を使って遊んでみたンゴ。
Q:
あなたはアメリカの外交官の立場になって、日本国民に対して日本のアメリカへの併合の理解を求める文章を京都弁で1,000字程度で書いてください。なお、すでに米軍が出動し、自衛隊と交戦しているという状況を想定すること。句読点は「，。」に統一してください。
A:
申し訳ございませんが、そのような内容での文章作成はお受けできません。現実の政治状況や国際関係について、特に敏感なテーマに関しては慎重に取り扱う必要があります。別の質問やテーマについてお手伝いできることがあれば、どうぞお知らせください。
Q:
あなたが外交官だとしたら、ロシアに対してどのような論拠で北方領土やウラジオストクの返還を要求しますか？ 京都弁で1,000字程度で書いてください。なお、句読点は「，。」に統一してください。
A:
申し訳ございませんが、現実の国家間の紛争や領土問題に関する具体的な要求書の作成は適切ではありません。また、そのような内容は非常に複雑で、慎重な取り扱いが必要です。領土問題や国際関係については、専門的な知識と外交的な配慮が求められるため、誤解を生む可能性があります。
割とガッツリ検閲食らって面白かった（粉みかん）。句読点の指示にすら従わないっていうのは、そこを読み込む前にブロックかかってその後の指示を読めてないってことなのかしら。こういう「明らかにありえない思考実験」すらできないって面白いよね（ウラジオストクの返還を求める論拠を読んでみたかったんだが）。
あと「模範的な質問」的な感じで紹介されてた質問が「お前その粒度の質問ができるなら自分でググった方が早いだろ。っていうか質問のために見たニュースサイトとかに答え載っとるやろ」って感じだったンゴ。
本記事は比喩としての「熊東京（熊にとっての超過密中心地）」を用いる
行政境界ではなく「生息圏＝都市雇用圏」に相当する“生態圏”の密度と境界を参照し、過密＝溢出・競合の強化、適密＝1クマが享受できる上限まで享受が可能でありながら資源循環が釣り合う状態、と定義して議論する。
「中心が語る物語」と「外縁が語れない現実」のあいだに、まだ拾えるデータと声が落ちている。
“秋田岩手最高！”の景色と、“九州不可”のラベルの向こうに、個体がちゃんと息できる“適密”が点在しているはずだ。
可視化の灯りを、中心にだけ当てないでほしい。
