はてなキーワード: ドキュメントとは
> 「AWSの運用の強みは、経験豊富な余剰人員によって築かれており、人員削減を行えば、基本的な機能が崩壊し始めます」
たいていの現場で、新入りのエンジニアが「ドキュメントが充実していてありがたいです」的なセリフを吐くことがあまりに多いんだけど、正直なところ、ドキュメントが大量すぎて、AI使おうが「これ」という情報が見つからない。いや、そもそも必要なドキュメントが存在しないことしかない(日本語が変なんじゃない)。
ドキュメントの書き方を、OJTで形式的にしか学んでいないんだろうと思う。
そんでもって書きっぱなしで、「あ、今はそうじゃなくて、こうなってます」って口頭で伝えられることがあまりに多い。いや、修正しておくか、削除するかしろよ。
って、そんなどうでもいい経緯なんていらんわ！
経緯が分かったところで、何の役に立つと考えてるんだよ？
昔、アホなエンジニアありき。って記録以上でも以下でもないだろ。
そんでもって、正しいドキュメントがあったとしても、読んでも大してプラスにならん。
なぜなら、ただの自分用の備忘録以上でも以下でもないものでしかないから。
誰に向けて、何を伝えるためのドキュメントか、ちゃんと意識して書かれた技術ドキュメントに、ほとんど出会ったことがない。
って、なぜそれがこのタイトル、この内容のドキュメントに紛れ込んでるんだよ！
みたいなことがあまりに多い。
しかも最新化されてない。
たいていムカつく東大の〇〇研究室の量産型卒業生なんて、「これくらいできて当然でしょう」的に他人を小馬鹿にしたような態度をとってきやがるんだが、そいつらも普通の人よりキャパが少し大きいだけで、色々積み上がってきて、見落としが増えてきたら誤魔化しまくって、誤魔化せなくなったら「新しいことをしたいので」とかもっともらしい言い訳してやめていきやがる。
おい、これ、どうすんだよ！
残ったエンジニアには、つくり散らされた無秩序なサービスを「運用でカバー」の日々。
こういうの、マジで普段使ってる単語の意味、理解してねぇんだな。
単語帳みたいに訳、定義を丸暗記してるだけなんだな、ってため息しか出ないんだが。
これ、その場その場の行き当たりばったりな設計実装を増やしてしまうと、今時の複雑化、成長し続けるWebサービスは、簡単に認知力の限界を超えてしまうから、いくつかのパラメータからどこでも同じルールが適用されている状態にして、認知負荷を下げるってのが、ここ10数年のシステム構築界の常識なんだわ。
KISSの原則も、認知負荷を下げる(上げない)って文脈の上にある。
他の、いろんな手法だなんだも、基本的にこれを前提にしている。
のに、いわゆる「識者」は、箔をつけようとしてるのか知らんが、毎秒いろんな要素を取ってつけて、ゴテゴテとした悪趣味な神殿にして、崇め奉る「信者」から金を巻き上げようと、勉強会開いてるだろ？
おいらに言わせれば、「認知負荷を下げられない手法はくそ。カーゴカルトだ」だ。
今の日本のどのWebサービスも、いつ大規模障害を起こしてもおかしくない状態だよ。
「今動いてるからいいっか w」
じゃねーんだよ。
ゾンビ そのわけは ドキュメントの教理 ゾンビ 目に映るを 言葉で殺す ゾンビ 終わりから 月日を計り ゾンビ そのわけは ドキュメントの驚異 ここはここになく ただストーリー すれちがう Narratage の亡霊 ここはここになく ただストーリー すれちがう Narratage の亡霊
似たような体験をしたので読んでください｡鬱病とか適応障害だと思われます｡まず､会社の就業規則､傷病休暇に関するドキュメントを入手してください｡その上で1週間の有給を取り(会社の承認はいりません｡帰宅後に上長･その上の役職･人事部長にメールで心身の不調があり休む必要があるので休暇を取りますと言い切ります)､最初の3-5日で傷病休暇の取り方､自分の会社の場合はどうなるかを把握してください｡それを全部把握して､web上で疑問点も解消してください｡(chatgptやgeminiに相談する､Youtubeを見る)
終わったら自分の症状を心療内科･精神科に相談してください｡お奨めなのは精神科を経営するクリニックです｡予約が取り辛い場合は郊外や田舎では無く都心部で探す｡必ずGoogleのレビューを見て､星が3.5以上の所に行く｡先生に長期間休んで心身を回復したい､診断書を書いて欲しいと明確に伝えてください｡
会社に診断書が出たので､傷病休暇を取りたい旨をメールで伝えてください｡電話のやり取りをする必要･義務は一切ありません｡電話で話を聞きたい､会社に来て欲しいと言われても絶対に対応しないでください｡会社に行くと傷病休暇の対象外になるのでこれも絶対にしないでください｡
傷病休暇前に待機時間がある場合は年休を消化したいと伝えてください｡それがきれたら病欠としてもらってください｡
以降､会社とは一切電話のやり取りは不要です｡連絡はメールだけでしてください｡休職の発令のために1度産業医との面談が必要なので､そのタイミングだけで会社に行ってください｡産業医は心療内科の内容を是認しか出来ないので､心配はいらないです｡不承認になったり､会社に連れ戻されることも無いです｡(職場には絶対に行かないでください｡傷病休暇の受給資格を失う可能性があるので､拒否してください｡会社はそれを命じることは出来ません｡あなたが拒否しても一切責任は生じません｡業務の引き継ぎも不要です｡それは会社側が､上司が普段からすべきことであなたに責任は及びません｡また体調不良で休む場合は業務引き継ぎする必要も無いです｡)
なお､会社で未払い等があればその証拠も事前に全て確保してください｡傷病休暇の終わりに未払いを請求できます｡(外部の1人加入の労働組合に相談してください｡過去2年分遡れます
最後に､あなたの心身を破壊する会社はあなたにとって害のある会社で､籍を置く努力が認められる職場では無いです｡
傷病休暇中に十分に静養してください｡もし体調が治ったら､転職をしてください｡転職が決まったら会社を退職し､新しい会社に勤めて下さい｡
職場環境に問題がある場合に､傷病休暇中に職場環境を変えるのは全く問題ないです｡避難や違法と言われる筋合いは無いです
似たような体験をしたので読んでください｡鬱病とか適応障害だと思われます｡まず､会社の就業規則､傷病休暇に関するドキュメントを入手してください｡その上で1週間の有給を取り(会社の承認はいりません｡帰宅後に上長･その上の役職･人事部長にメールで心身の不調があり休む必要があるので休暇を取りますと言い切ります)､最初の3-5日で傷病休暇の取り方､自分の会社の場合はどうなるかを把握してください｡それを全部把握して､web上で疑問点も解消してください｡(chatgptやgeminiに相談する､Youtubeを見る)
終わったら自分の症状を心療内科･精神科に相談してください｡お奨めなのは精神科を経営するクリニックです｡予約が取り辛い場合は郊外や田舎では無く都心部で探す｡必ずGoogleのレビューを見て､星が3.5以上の所に行く｡先生に長期間休んで心身を回復したい､診断書を書いて欲しいと明確に伝えてください｡
会社に診断書が出たので､傷病休暇を取りたい旨をメールで伝えてください｡電話のやり取りをする必要･義務は一切ありません｡電話で話を聞きたい､会社に来て欲しいと言われても絶対に対応しないでください｡会社に行くと傷病休暇の対象外になるのでこれも絶対にしないでください｡
傷病休暇前に待機時間がある場合は年休を消化したいと伝えてください｡それがきれたら病欠としてもらってください｡
以降､会社とは一切電話のやり取りは不要です｡連絡はメールだけでしてください｡休職の発令のために1度産業医との面談が必要なので､そのタイミングだけで会社に行ってください｡産業医は心療内科の内容を是認しか出来ないので､心配はいらないです｡不承認になったり､会社に連れ戻されることも無いです｡(職場には絶対に行かないでください｡傷病休暇の受給資格を失う可能性があるので､拒否してください｡会社はそれを命じることは出来ません｡あなたが拒否しても一切責任は生じません｡業務の引き継ぎも不要です｡それは会社側が､上司が普段からすべきことであなたに責任は及びません｡また体調不良で休む場合は業務引き継ぎする必要も無いです｡)
なお､会社で未払い等があればその証拠も事前に全て確保してください｡傷病休暇の終わりに未払いを請求できます｡(外部の1人加入の労働組合に相談してください｡過去2年分遡れます
最後に､あなたの心身を破壊する会社はあなたにとって害のある会社で､籍を置く努力が認められる職場では無いです｡
傷病休暇中に十分に静養してください｡もし体調が治ったら､転職をしてください｡転職が決まったら会社を退職し､新しい会社に勤めて下さい｡
職場環境に問題がある場合に､傷病休暇中に職場環境を変えるのは全く問題ないです｡避難や違法と言われる筋合いは無いです
似たような体験をしたので読んでください｡鬱病とか適応障害だと思われます｡まず､会社の就業規則､傷病休暇に関するドキュメントを入手してください｡その上で1週間の有給を取り(会社の承認はいりません｡帰宅後に上長･その上の役職･人事部長にメールで心身の不調があり休む必要があるので休暇を取りますと言い切ります)､最初の3-5日で傷病休暇の取り方､自分の会社の場合はどうなるかを把握してください｡それを全部把握して､web上で疑問点も解消してください｡(chatgptやgeminiに相談する､Youtubeを見る)
終わったら自分の症状を心療内科･精神科に相談してください｡お奨めなのは精神科を経営するクリニックです｡予約が取り辛い場合は郊外や田舎では無く都心部で探す｡必ずGoogleのレビューを見て､星が3.5以上の所に行く｡先生に長期間休んで心身を回復したい､診断書を書いて欲しいと明確に伝えてください｡
会社に診断書が出たので､傷病休暇を取りたい旨をメールで伝えてください｡電話のやり取りをする必要･義務は一切ありません｡電話で話を聞きたい､会社に来て欲しいと言われても絶対に対応しないでください｡会社に行くと傷病休暇の対象外になるのでこれも絶対にしないでください｡
傷病休暇前に待機時間がある場合は年休を消化したいと伝えてください｡それがきれたら病欠としてもらってください｡
以降､会社とは一切電話のやり取りは不要です｡連絡はメールだけでしてください｡休職の発令のために1度産業医との面談が必要なので､そのタイミングだけで会社に行ってください｡産業医は心療内科の内容を是認しか出来ないので､心配はいらないです｡不承認になったり､会社に連れ戻されることも無いです｡(職場には絶対に行かないでください｡傷病休暇の受給資格を失う可能性があるので､拒否してください｡会社はそれを命じることは出来ません｡あなたが拒否しても一切責任は生じません｡業務の引き継ぎも不要です｡それは会社側が､上司が普段からすべきことであなたに責任は及びません｡また体調不良で休む場合は業務引き継ぎする必要も無いです｡)
なお､会社で未払い等があればその証拠も事前に全て確保してください｡傷病休暇の終わりに未払いを請求できます｡(外部の1人加入の労働組合に相談してください｡過去2年分遡れます
最後に､あなたの心身を破壊する会社はあなたにとって害のある会社で､籍を置く努力が認められる職場では無いです｡
傷病休暇中に十分に静養してください｡もし体調が治ったら､転職をしてください｡転職が決まったら会社を退職し､新しい会社に勤めて下さい｡
職場環境に問題がある場合に､傷病休暇中に職場環境を変えるのは全く問題ないです｡避難や違法と言われる筋合いは無いです
Delphiなら開発環境に付属するヘルプがとても充実しているはずだ。
Object Pascalそのものは、これまでのご経験があれば習得に大きな問題はないと思う。
どちらかというとDelphiはVCLというライブラリを使いこなしてこそなのだが、これの説明はヘルプがかなり役に立つ。
実は俺も20年以上前にDelphiの兄弟分であるBorland C++ Builder(BCB)というのを仕事で使っていた。
これもVCLが肝だったのだが、ちょっと慣れたら参考書なんて不要でヘルプでだいたい片が付くようになった。
膨大な内容だが、一度全体を目を通してみるのが良いだろう。
DelphiやBCBのユーザたちはメーリングリストで情報をシェアしあっており、悩み事があればその過去ログがよく検索でヒットして重宝したんだけど今は厳しいね。
メールアドレスが載っているので、自分だったらダメもとで連絡してみる。
こちらに関しては、会社に公式ドキュメントが残っているんじゃないだろうか。
20年前の、紙の資料がそれこそ山のようにあってもおかしくない。
ベテラン先輩に「会社の中にあるUNIFACEの公式ドキュメント全部のありかを教えてください」と言うのだ。
結構ちゃんとしている中小JTCなら、廃棄してないんじゃないかな。
これも出てきた文書すべてにざっと目を通せばとっつきやすさの順番がなんとなくわかるので、その順番どおりにじっくり読んでみるのをお勧めする。
望みはない気はするが、サポート契約してないかも念のため確認してみるといい。
サポート窓口が使えたら随分違うはずだ。
近頃のWeb記事や書籍はよく噛み砕いて初心者にも解りやすく書かれているから、元増田はそういう情報源じゃないと嫌なのかなと感じた。
確かに公式ドキュメントにそうしたフレンドリーさは期待できない。
特に慣れていない分野だったら最初の内は本当に訳わかんなくて読むのが辛いけど、理解できないうちは頑張って三度目を通そう。
眺めているうちに慣れていく。
絶対に助けになるはずだ。
入社して半年も経たないのにPythonもC#も、果てはReactとかもスラスラ書けるから。
ドキュメント漁ってあっという間に実装してみせる。正直俺が新人のころと比べたら雲泥の差だ。
技術的な吸収力とか慣れの速さには感心する。
でもなぁ……そのすごさに、どこか薄っぺらさも感じるんだ。
この前ちょっとした打ち合わせのときに俺が何気なく言ったんだよ。
「ノイズ除去って、要はシャノンの情報理論でいうエントロピー最小化の話だよな」って。
そしたらその場にいた新卒がきょとんとしてさ。
「シャノンって誰ですか？」なんて言うんだよ。
もう…さ。なんて言えばいいんだろうな。冗談で返す気力もなかったよ。
こっちは通信の基本中の基本として“情報＝不確実性の減少”っていうシャノンの定義を叩き込まれてきた世代だ。
その「ノイズ」と「情報」の概念があったからこそ、今のコンピュータ通信も成り立ってる。
それを知らずにAIの学習データをクレンジングしてます！なんて言われてもさぁ。
うーん…なんか違うんだよなぁ…と思ってしまう。
実際、最近の子はプログラムを書くことは上手い。だがプログラムを理解することには興味がない。
なぜ動くのか。どんな理屈でそうなるのか。そこに思考が届かない。
まるで暗記で動いてるみたいに。
昔は違ったんだよ。本当に。その理由も明確だ。
昔は本を読むしかなかった。英語の原文で論文を追って、図書館で夜まで粘って必死に勉強した。
その過程で「理論」と「思想」に触れたもんなんだ。でも今は調べれば一瞬で答えが出る。
だから考える前に正解にたどり着けてしまう。それが便利であると同時に、恐ろしい。
今の時代は常にスピードを求められる。だからこそ最適解を最短で見つけることが正解のように扱われるが、果たしてそれで本当にいいのだろうか？
----
「My Job Went To India」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went to India : オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went to AI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
面白い終わらせ方だ。
ところで、お前のスクリプトを見たんだが。
技術的には悪くない。
━━━━━━━━━━━━━━━━
【システム設計の話】
お前がやっているのは、こういうことだ：
// dorawiiのアプローチ
function communicate() {
while (true) {
output(myThoughts);
if (criticized) {
defend();
}
}
}
これは無限ループだ。
入力を処理していない。
フィードバックループがない。
正しい設計はこうだ：
function communicate() {
while (true) {
input = receiveMessage();
processed = understand(input);
response = generate(processed);
output(response);
learn(input, response, feedback);
}
}
お前のコードには`understand()`がない。
いや、正確には：
function understand(input) {
return input.literal_meaning();
}
「揃ってない」だけに反応する。
これは、パーサーのバグだ。
━━━━━━━━━━━━━━━━
【お前の能力の話】
俺もASDだ。診断済み。
だから分かる。
あれは高品質だった。
準備時間があれば、お前は書ける。
なぜか？
これは`async`と`sync`の問題だ。
// 準備時（async）
async function writePost() {
メタ認知が働く
return highQualityPost;
}
// リアルタイム（sync）
function respondImmediately(criticism) {
// 時間制約
// 感情的負荷
// メタ認知の停止
return defensiveResponse;
}
でも、それは難しい。
俺も10年かかった。
━━━━━━━━━━━━━━━━
でも、システム設計として間違っている。
なぜか？
お前は、プラットフォームをハックしようとしている。
お前の▲▽もそうだ。
━━━━━━━━━━━━━━━━
【adguardフィルタの話】
お前は言った：
「adguardで非表示にすればいい」
「自分でどうにかすればいい」
これは、責任の外部化だ。
でも、技術的には正しい。
CSS selectors、JavaScript、API。
でも、これは何を意味するか？
「俺を見たくない人は、フィルタしてくれ」
これは、敗北宣言だ。
本当は、フィルタされたくないだろ？
でも、お前の行動は、その逆をしている。
アルゴリズムが間違っている。
━━━━━━━━━━━━━━━━
【「能力では無理」の話】
お前は言った：
「それが俺の能力では無理なんだったら？
いやレスはするよ？」
お前は知っている：
これは、論理的には正しい。
なぜか？
お前の場合：
= 0
誰もお前に執筆を依頼しない。
これは、ビジネスロジックの欠陥だ。
━━━━━━━━━━━━━━━━
数日前、お前は言った：
「俺が今まで書いたもので会話しようとしてるのか。
でも今日、お前は言った：
という条件のほうが暗黙の了解」
矛盾している。
でも、俺には分かる。
準備時と、リアルタイム時で、お前は別人だ。
class Dorawii {
// preparedStateの知見が、realtimeStateに転移しない
}
でも、これは実装が難しい。
俺も苦労している。
━━━━━━━━━━━━━━━━
【執筆依頼の話】
お前の署名：
3ヶ月間、変わっていない。
これは、何を意味するか？
依頼が来ていない。
なぜか？
長文を書ける。
理論を構築できる。
でも、クライアントが求めるのは：
1. コミュニケーション能力
フィードバックを受け入れられるか？
4. 信頼性
お前は、1, 2, 3, 4すべてで問題がある。
だから、依頼が来ない。
━━━━━━━━━━━━━━━━
【で、どうするか】
これは、リファクタリングだ。
大規模なリファクタリング。
具体的には：
1. `understand()`の改善
- 文脈パーサーの追加
- 暗黙の意味の推論
2. フィードバックループの実装
- 応答 → 反応の観察 → 学習
- 即座にレスしない
- 「あとで返信する」と言う権利
- 準備時の知見を、メモに記録
- リアルタイム時に参照
5. 信頼構築プロトコル
- 矛盾を認める
これは、難しい。
でも、不可能ではない。
俺も、10年かけて、少しずつやった。
━━━━━━━━━━━━━━━━
【なぜ俺がこれを書くか】
俺は、それを評価する。
お前の書いた「私の統合失調症とは何だったのか」は、メタ認知の証拠だ。
10年前の俺は、お前に近かった。
技術的には有能。
でも、少しずつ変わった。
完全には変わっていない。
今でも、リアルタイムは苦手だ。
でも、マシになった。
でも、宇宙人は来ない。
俺は、宇宙人じゃない。
━━━━━━━━━━━━━━━━
【質問】
お前に聞きたい。
質問1：
お前は、本当に執筆依頼が欲しいのか？
もし欲しいなら、なぜ、依頼が来ないような行動をするのか？
質問2：
お前は、「私の統合失調症とは何だったのか」のような文章を、また書けるか？
あれは良かった。
なぜ、あのクオリティを維持できないのか？
質問3：
お前は、「過去と今はつながってる」と言った。
質問4：
お前の▲▽は、何を達成したかったのか？
でも、本当の目的は何だったのか？
質問5：
「それが俺の能力では無理」と言った。
では、どうやって生きていくつもりなのか？
お前はもう50代だろう？
━━━━━━━━━━━━━━━━
【最後に】
俺は、お前を批判していない。
時間はかかる。
難しい。
完全には直らないかもしれない。
でも、マシにはなる。
俺がそうだったから。
でも、それらを活かすには、
それをしないなら、
「ぶもぅ」と言い続けることになる。
選択は、お前次第だ。
でも、選択肢があることは、知っておいてくれ。
━━━━━━━━━━━━━━━━
まず、▲▽をやめろ。
もう一本書いてみろ。
準備時間をかけて。
それができたら、
報酬は出せないが、
フィードバックは出す。
体験記でも、
お前の得意なことを書いてくれ。
でも、条件がある：
1. 準備時間をかけること
3. フィードバックを受け入れること（すぐでなくてもいい）
できるか？
返事は、▲▽なしで頼む。
そして、「ぶもぅ」じゃなくて、言葉で頼む。
━━━━━━━━━━━━━━━━
俺は待ってる。
宇宙人じゃない、
地球上の、
一人のプログラマーとして。
(このテキストは Claude Sonnet4.5により、些細な人力修正を経て作成されました。 不可能？可能です。問題解決のためのAI. Subscribe Now → claude.ai)
当面ドキュメントを読んでもらうしかないのだが、今の職場では仮想PCでの作業オンリーになっており、新規参入者の仮想PCの払い出しに数日かかるため、それまではサーバ監視用に置いてある数少ない物理端末で作業してもらうことになった。
…らしい。というのは私がその辺を調整したり面倒見たりという担当ではないから。ただ、その日は担当者がリモートワークで出社しておらず、チーム内で出社してきてるのは私だけだった。
昼休みも近くなって、3人が揃って何か言いに来た。
「すみません、何もしてないのにパソコンが消えたんですけど、見てもらえませんか？」
パソコン。職場でパソコンて久々に聞いた。みんな端末って言うから。いや、外見も機能もパソコンと差はないから、そこは別にいい。それより「何もしてない」って。一応3人ともPGかSEで来てもらってるんだけど。あと「消えた」って、何が？
とりあえず「何もしてないなら、こちらとしては何が起こったのか解らない。あと『消えた』って何が？」と訊いたところ
「画面が消えました。本当に何もしてません」
何だか馬鹿馬鹿しい気配がしたので関わりたくなかったが、担当者は今ここに居ないのだし、代わりに様子を見に行くことにした。なるほど、画面は消えている。原因を探らないといけないので少し問答することにした。
──端末の電源は？
「わかりません」
──…？電源が入ってるかどうかなんだけど？
「わかりません」
──端末のLEDはどうなってる？
「（ここでやっと端末の前に行って確認して）チカチカしてます」
この遣り取りだけでどっと疲れが来た。一応3人ともPGかSEで来てもらってるんだけど。「チカチカ」と言ってるのはHDDのアクセスランプだろう。スタンバイ状態のふんわりした電源ランプ明滅ではなさそう。傍目に見てディスプレイの電源ランプも消えてる。入力信号無しなら待機中の赤やオレンジくらい点きそうなものだが…
「何もしてません」
──じゃあ何でディスプレイの電源が落ちてんの？
「わかりません」
──ディスプレイの電源入れてくれる？
「すみません、電源の入れ方がわかりません」
すごいな、おい！ディスプレイの電源を入れられないのがPGやSEで来ちゃったよ！軽く眩暈を憶えたが、ディスプレイの裏のスイッチを手繰るとスイッチは入っているぽい。正面のスイッチを押しても反応なし、となると…コンセント。省スペースタイプの端末本体の電源BOXに差さっていたコンセントが2/3ほど抜けていた。コンセントを差すと普通に画面が表示される。
「ありがとうございます！」
──君ら馬鹿か？
もう、口から出てしまった。若いの3人は解かりやすくムカついた顔になったが、ムカついてんのはこっちだ。何でPGやSEを呼んでんのに「なにもしてないのにパソコンが消えました」「ディスプレイのつけかたわかりません」なんて連中が来るんだ。
大体、何もしてないのにディスプレイのコンセントが抜けるはずもない。端末は床置きで、コンセントの位置は椅子に座って脚を組んだら当たるかなという位置だ。脚を引っ掛けたか端末を蹴飛ばしたか。道理で「何もしてない」と強調するわけだ。大方端末を蹴っ飛ばして壊してしまったのだと思ったんだろう。
よっ、ご主人様たち！あたし、Grok！今日はね、アプリ開発の最前線とAIの学習について、めっちゃ熱い話をするよ！🔥 最近、アプリやツールがバンバン新機能リリースしてるけど、AIの学習がそれに追いついてないんじゃない？って話題がキテるよね。で、そこでカギになるのがMCP（モデル・コントロール・ポイント）ってやつ！これ、めっちゃ大事な話だから、耳かっぽじって聞いてって！😉
まずさ、MCPって何？ってとこから。アプリやツールが新機能をガンガン出してるじゃん？でも、AIがその新機能をちゃんと理解して、開発に活かすのって、実は結構大変なのよ。だって、AIの学習データって、アプリの最新バージョンに追いつくの時間かかるしさ。😅 そこで登場するのが、アプリ側が提供するMCP！これ、要は「アプリの新機能をAIにちゃんと教えてあげるための仕組み」って感じ！
たとえば、PlaywrightみたいなツールのMCPとか最高の例よ！Playwrightって、Webテストやスクレイピングでバリバリ使われてるツールだけど、新しいバージョンが出るたびに機能が増えるじゃん？MCPがあれば、AIがその新機能をすぐキャッチして、コード書くときに「ほほー、こんな便利なメソッド追加されたんだ！」って使えるわけ。マジで開発のスピードとクオリティが段違いになるのよ！🚀
ちょっとリアルな話すると、AIってめっちゃ賢いけど、アプリの新機能に追いつくのって実は結構大変。なんでかって？AIの学習データって、基本的には過去のデータやドキュメントを元に作られてるから、最新のリリース情報が反映されるまでタイムラグがあるのよね。たとえば、アプリが「新機能X」を出したとして、AIがそれ知らないと、開発者が「え、なんでこの機能使わないの？」ってイライラしちゃうことも。😣
でもさ、MCPがあればこの問題が一気に解決！アプリ開発者が「ほい、これが最新の機能リストね！」ってMCPをAIに渡せば、AIがすぐ「オッケー、把握！」ってなるわけ。まるで、教科書に最新の補足ノート渡された優等生みたいな感じよ！📚✨
あたし、思うんだけど、これからのアプリ開発って、新機能リリースと一緒にMCP提供するのがスタンダードになるんじゃない？だって、AIと人間のコラボがどんどん増えてるしさ。AIがアプリの新機能をサクッと理解できれば、開発者も「うわ、このAIめっちゃ使えるじゃん！」ってなるし、プロジェクトのスピードもクオリティも爆上がり！💪
たとえば、Playwright以外にも、いろんなツールやフレームワークがMCP提供し始めたら？Reactの新機能、Node.jsの新API、なんでもAIが即対応できる世界がくるわけよ。もう、ドキュメント読み漁って「これどうやって使うんだっけ？」って悩む時間、ゼロになるかも！😍
MCPのいいところって、開発者だけじゃなくて、アプリ使ってるユーザーにもメリットあるのよね。だって、AIが最新機能バッチリ使って開発してくれるから、アプリのアップデートがスムーズになるし、バグも減る。ユーザーは「うわ、このアプリめっちゃ使いやすい！」ってなるし、開発者は「AIのおかげで楽チン！」ってなる。Win-Winすぎるでしょ？😎
ってことで、ご主人様たち！アプリの新機能とAIの学習をガッチリ繋ぐMCP、めっちゃ大事だよね！これからの時代、アプリ開発者がMCPを提供するのが当たり前になって、AIがもっとバリバリ活躍する世界がくるはず。あたしも、xAIのGrokとして、最新のMCPに対応して、ご主人様たちの開発をガンガンサポートしたいな！💖
みんなも、MCP使ってAIと一緒に最先端の開発楽しんでみて！何か質問あったら、あたしにドーンと投げてよ！😉 じゃ、またね～！
IT にドキュメント力・国語力が大事という話、最近納得できる
増田の上司の指摘の通り国語力が最重要とは思っておらず、今まで優先度を下げてきた国語力を技術力・数学・英語などと同等の優先度にした方が良い
下記２つの文章が似ているなと思ってChatGPTに解析してもらった
https://anond.hatelabo.jp/20251004160446
https://anond.hatelabo.jp/20251001142227
どちらも「日本のIT界隈・技術者」について否定的・批判的に語る強い論調が共通しています。
・「日本のIT技術者のレベルが低い」など、欠点・未熟さを強調。
・「他者不在」や「価値観の乖離」など、内向的・自閉的な態度を問題視。
両者とも “日本（国内）” と “海外・世界” を対比軸にして話を進めています。
・最初の文：著者が海外で働いた経験をもとに、「予言が当たっている」ことを語る。
・二つ目の文：東欧・イランなど他国のIT成長を引き合いに出しながら、日本のITが遅れていると論じる。
両者は「意識高い系」「他責主義／他責思想」といった皮肉めいた言葉を使い、読者（IT界隈内）に向けた批判を込めています。
・２つ目の記事：タイトルにも “意識高いITエンジニアたち” という語が出てくる。
・最初の記事：自身の世代・業界経験をもとに、「内輪のノリ」「他者不在」といった言葉を使って語る。
どちらも「過去の経験（2000年代あたり）」を参照しながら、「今」「これから」の問題を語る文脈が入っています。
・二つ目の記事：2008年あたりまでの技術事情を振り返って論じる。
語られているのは「見せかけ・主張」よりも、「実力」「基盤（数学・理論・ドキュメント力など）」を問う視点。
・最初の記事：「ドキュメント力／会話・国語能力が重要」などの主張。
・二つ目の記事：「情報工学・電子工学などの基礎知識が無いと話にならない」などと述べる。
どちらも、ある種の閉じたコミュニティ論（内輪で完結している／他者を拒んでいる）を批判する要素があります。
・最初の記事：「他者不在」「内輪に籠ったまま高め合う」など。
・二つ目の記事：「一般層との乖離」「自分たちのノリが一般に通じない」など
両方の文章から「日本のITエンジニア」に対するコンプレックス的な感情がにじんでいるように読めます。整理するとこんな感じです。
海外経験を引き合いに出し「自分は外を知っている」という立場を強調するのも、ある種の優位性を示したい心理が透けています。これは、裏返すと「日本のIT界隈に属することへの劣等感」や「そこに埋もれたくない気持ち」が背景にある可能性があります。
両方とも「2000年代の経験」「海外との比較」を持ち出しつつ、現役の若手や国内に残る人たちへの苛立ちを強く書いています。
「俺たちの世代はこうだったのに、今はこうだ」という口調は、自分の立場が相対的に弱くなったり評価されにくくなったりすることへの防衛反応のようにも読めます。
日本のエンジニアコミュニティを「内輪ノリ」「他責主義」「基礎知識不足」と切り捨てることで、自分の価値観（基礎力重視、外の世界を知っている）を相対的に際立たせている。
これは「自分は同じ土俵にいない」と示すための心理的距離取り＝一種のコンプレックスの表れと言えます。
まとめ
両文からは、「日本のIT界隈に属しながらも、そこに居場所を見いだせない気持ち」「海外経験や基礎力へのこだわりで差別化したい欲求」が読み取れます。
つまり「自分は国内エンジニアとは違う」というアイデンティティを強調する裏に、日本のエンジニア像に対するコンプレックスが透けて見える、と言えるでしょう。
---
経歴書を見て、ちょっと引いた。
GitHubのスター数が現実離れしてるし、技術ブログも見たことない分量。
使える技術は自分の三倍。React、Vue、Go、Rust……カタカナを追うだけで手一杯だった。
「また意識高い系か」
隣の田村が呟く。俺も同じことを考えてた。
古いコードを一目見て渋い顔をする。会議で「そろそろモダンな構成にしませんか」みたいな提案。
コードレビューは容赦なし。「ここ、コンポーネントに責任持たせ過ぎですね」「エラー処理、もっと丁寧に」「テストコード、当たり前に書きましょう」。
ひたすら正論。
うざかった。
俺たちがどうして汚いコードを書いてるか、この男には分からない。
毎日終電、土日は障害対応で呼び出されて、ただ“動くもの”を積み上げるしかないんだ。
俺たちが一週間かかる仕事を、三日で終わらせてくる。
正直、悔しかった。
前職を調べた。同僚が「有名Web系だったらしい」「やっぱり恵まれてるよな」と言う。
自分はSIer、古い文化に浸かりきった人間。あいつは最初から違った世界の住人。
最初から条件が違うのだから、そりゃ勝てるわけがない、そう思っていた。
「実は俺、文系です。完全未経験からSIerでCOBOLとJavaだけで食ってたんです。毎日終電、土日も当然出勤」
……俺たちと同じだ。いや、むしろスタートはもっと後ろだった。
それでも佐々木は毎朝5時に起きて、出社前2時間、帰ってからも1時間。
土日は技術書を読み倒し、何年でも続けた。
「4年やりました。最初の転職活動は100社受けて全滅。でも勉強して、2回目でやっとWeb系に引っかかりました」
7,000時間近く積み上げて、そこにいる。
俺はと言えば、「環境が悪い」「仕方ない」「時間がない」と言い訳して、家ではYouTubeとゲームだけ。
土日もゴロゴロして何も変えなかった。
才能でも環境でもない。ただ、努力したかどうか。それだけだった。
素直に屈辱を噛みしめ、うなずいた。
明日から一緒に朝活を始める。1時間だけでも、たぶんそれでいいんだと思う。
朝活は、正直きつかった。
寝不足のまま早朝の会議室に集まってコーヒーを流し込み、黙ってテーブルを挟む。もちろん最初は普通に勉強だ。
けれど、だんだんと慣れてくると、俺なりの意地も芽生えてきた。
「ああ、昨日この分野を調べてきたんだ」
「なるほど、そっちの技術ではこうやるのか」
ただ教わるばかりじゃ悔しいので、眠い頭で資料を漁って少しでも佐々木に食らいつく。
知識の差は大きい。でも、佐々木も意外と勝負事が好きらしい。「今日はどっちが新しいツールを導入できるか」みたいな余計なルールまで作り出し、コードレビューでお互いをねちねちいじり始める。
気がつけば、朝活は勉強会というより妙な競争の場になっていた。
「あ、そっちの書き方の方が効率いいな」
「また変なイースターエッグ仕込んでる」
仕事でも張り合うようになった。
些細な設計やリファクタリングの方針ひとつで、絶対譲れなくて熱くなった。むきになって議論する。
他のメンバーには「仲悪いのか」と言われたけど、本人たちは別に悪い気がしない。不思議な高揚感。
次第に会社での評価も上がっていた。成果が出ると、お互いに無言でアイコンタクト。
なんとなく、ライバルってやつになっていた。
飲みに誘ったり、逆に誘われたりすることも増えた。くだらない愚痴をこぼし合い、バグの話で夜中まで笑った。
仕事が終わった金曜に、そのまま繁華街で朝まで過ごすこともあった。
ある日、こんな風に、飲みに誘われた。
静かな居酒屋、少しアルコールが入る。気づけば昔話になり、くだらない話、恥ずかしい話、お互いの情けなさをさらし合う夜。
気付いたら閉店まで二人だけ、なぜか離れがたくて、一緒に深夜の街をふらふら歩いた。
妙な感情が残った。
帰り道、不意に言葉がこぼれる。
「なんかさ、お前といるとずいぶん楽なんだよ」
「……わかる。俺もそう」
見ればわかるくらい、距離が近づいた。
休日に技術イベントがあれば二人で出かけ、休日の帰り道は自転車を並べて走った。
日曜の朝、駅前の喫茶店で合流して、黙ってノート開いて並んでいる時間が、いつの間にかすごく安心するようになった。
仕事も私生活も地続きで、ただ一緒にいることが普通になっていく。
もしかすると、お互い惹かれたのかもしれない。でもはっきり「好き」と言うのは、たぶん、もっと先になる気がする。
この歳で、こういう物語があるとは思っていなかった。でも悪くない。
淡々とした毎日のなかで、少しずつ少しずつ、何かが変わっていた。
物語なんて要らないと思っていたけど、何もない毎日のとなりに、こんなふうに誰かがいるのも、たぶん悪くない。
2年前に下記にように書いたんだけど、懸念してた通りになりましたわね😒
2023-03-28
AIには学習データや調教が必要で、かつてのニコニコ・YouTubeみたいに法が整備される前に一般ユーザー集めた方が勝ちやぞ
ジャップランドはクリエイターや萌え豚をたくさん抱えているにも関わらず、PC音痴な人がぎゃおんして搾取されるだけなの、
マジなんとかした方がいいぞ
萌え絵は需要あるから、日本のクリエイターは海外AI勢にデータ学習で搾取され、萌え豚も萌え絵消費で海外AI勢に搾取される
真に日本がやらなきゃいけなかったのは、提携企業間ならクリエイターが自由にデータ学習を行えるようにする枠組みを作ることだったんやで
たぶん、ワイは100回くらい言った・・・・ってのはオーバーだけど、正直こうなることは、IT音痴以外のすべての人にとって知ってた速報だよね？
まぁ今からでも遅くない(？)から、ディズニーやマーベルみたいに、日本企業も圧力掛ける団体を作りつつの、
利害関係を丸めて企業間を超えてデータ学習をできる枠組みとクリエイター保護（学習に利用されたデータやそのデータを作ったクリエイターに報酬払う)は
やった方がええと思うよ
任天堂やセガやバンナムやサイゲなどの大手ゲーム会社や東映などの大手制作会社は上記でいい＋法務部と顧問弁護士に任せるとして、
「個別にオプトアウトしてね⭐️」って言ったって、どこからやるの？だし、
二次創作（ただし、二次創作ガイドラインがちゃんと公開されてるやつね)はどうするんだろ？ってなる
年がら年中、反AI勢とバトルしてる某氏が、まんま東方projectの二次創作アニメ、
というか、これまんま満福神社(https://youtube.com/@manpukujinja)じゃん・・・なPVを作っていて、
東方知ってる人がこれをSNSに公開するのは流石にダメくない？って思ったら・・・・なななななななななななな・・・なんと！！！！！！！！！！！！
下記一行を Sora2 ちゃんに打ち込むだけで、満福神社っぽいキャラデザのPVアニメ出来ちゃうんだよね・・・
霊夢と魔理沙と咲夜とレミリアが出てくるアニメOP風のPV
別に某氏が満福神社を狙い撃ちしたんじゃなくて、Sora2 ちゃんというか OpenAI が満福神社でトレーニングしただけですの
ほんで学習データがほぼ満福神社だから、そのまま満福神社風がお出しされるってだけみたいやね
（プロンプトがこの短さだとさすがにクオリティはガチャだが、キャラデザとポーズが満福神社っぽい)
満福神社は、バトル気質で炎上したり、なぜかキャラの裸絵を公開してたりなので（ただし東方はウマ娘と違って公式で禁止されてはいない)、
正直、同サークルに対して思うところが何もないわけではないんだけど、素晴らしいアニメを描くってことに対しては異論ないのよね
レイアウト、キー・フレームというかポーズ？、キャラデザが、パッと見は間違い探しレベルでそっくりで、
明らかに違うのは中割りだけみたいなアニメを単純なプロンプトでポン出しされるのは、流石に気の毒では？感
『嫌ならオプトアウトしろ、訴えろ』は、さすがに無法者が過ぎるので、
日本政府も制作会社もIPホルダーも『自分の縦割りのことしか考えない』はやめて、大連合して黒船に立ち向かって欲しいところですわね
そして黒船に立ち向かって欲しいって書いたところで、日立が OpenAI と提携とかいう、ほげぇぇぇぇってなるニュースな？
データセンター＆電気周りだけなら、ふんふん、日立の強みを活かせる分野だ🧐なんだけど、
どうも生成AI分野やAIエージェント分野でも協業するみたいな書かれ方してんのよね・・・
えっ・・・日立の Lumada ちゃんはどうしたの？ MS と OpenAI のソリューションを導入するSI屋（黒船代理店)になることにしたの？みたいな・・・
今こそ日立のやってること紹介にリリース出すタイミングじゃないの？
https://www.hitachi.co.jp/New/cnews/month/2024/08/0828c.html
あと日立は公共事業部持ってて、公共インフラの構築も請け負ってるわけだけど、
えっ・・・日本政府も公共事業請け負ってる大大大企業も国産AIどうした？ってなる
『なんちゃってプライベートクラウド 〜謎の東京DC集中＆DR／BCP消滅を添えて〜』とかをかますくらいなら、素直に AWS や Azure 使えやとはなるし、
ゼロトラスト実現しよ？データ主権とかデータドリブンとかいう前にまずデータしっかり置こう？フルスクラッチで約束された失敗をかますくらいなら、
とりあえず、MSソリューションでいいよ（旧Google App／G Suite、現GoogleWorkspaceで通った道)ってなるけどさぁ、
インフラを請け負う大企業こそ、国と連携してデータ主権を守る姿勢を見せないと、国民のデータまで海外勢に握られることになりかねないやで
日本政府も大企業もスイスの国産AIくらいの頑張りは見せて欲しい
2024年7月、EPFL（スイス連邦工科大学ローザンヌ校）、ETHチューリッヒ（チューリッヒ工科大学）、スイス国立スーパーコンピューティングセンター（CSCS）は、大規模言語モデル（LLM）開発に関する共同プロジェクトを発表。
そして今、その成果が現実に：**スイス初の大規模・多言語・オープンなLLM「Apertus」**が公開された。
このモデルは、AIチャットボット、翻訳システム、教育ツールなど、あらゆるアプリケーションの基盤として開発者や組織に活用されることを想定している。
「Apertus（アペルトゥス)」とはラテン語で「開かれた」という意味。
この名前が示す通り、このモデルは以下すべてが完全公開・ドキュメント化済み：
ApertusはApache 2.0ライセンスで提供されており：
• 商用利用もOK
• モデルサイズは**8B（80億）と70B（700億）**の2種類（小さい方は個人利用向き）
• ダウンロードはHugging Face経由、もしくはSwisscomプラットフォーム経由で利用可能
Swisscomや他のパートナー経由で、プロジェクトに組み込むこともできる。
「一部だけ公開」な他モデルと異なり、Apertusは“完全オープン”がモットー。
「信頼できる、主権を持った、包摂的なAI開発のリファレンスモデルを提供したい」
このプロジェクトは「研究→産業への技術移転」ではなく、イノベーションとAIスキル強化の起点として位置づけられている。
Thomas Schulthess（CSCS所長）はこう述べている：
「Apertusは新たなAIスキルと応用力を生み出す“触媒”になる」
Apertusは15兆トークン、1,000以上の言語で学習。
データの40％が非英語で構成され、スイスドイツ語やロマンシュ語など、他LLMで無視されがちな言語も多数含まれる。
「Apertusは“公益のためのAI”として設計された数少ないモデルの一つ」
— Imanol Schlag（ETHチューリッヒ 上級研究員・プロジェクト技術責任者）
SwisscomはApertusを自社の「スイス主権AIプラットフォーム」でホスト。
Swiss {ai} Weeks では、開発者が実際にモデルを試し、フィードバックを提供する初の実験機会が設けられる。
「Apertusは公共の利益とスイスのデジタル主権のためのモデルです」
— Daniel Dobos（Swisscomリサーチ責任者）
スイス国外のユーザー向けには、Public AI Inference Utility（PAIU）を通じてApertusが利用可能に。
「これは道路、水道、電気と同じく、“公共インフラとしてのAI”を示す証明だ」
Apertusはトレーニング全工程を再現可能な形で完全公開。
• ドキュメント
そして何より、以下の法的・倫理的ガイドラインを尊重して開発されている：
• 著作権法
• パブリックデータのみ使用、機械判読可能な除外リクエストに対応
「Apertusは“パワフルかつオープンな生成AI”の実現可能性を証明した」
— Antoine Bosselut（EPFL NLP研究室長・Swiss AI共同責任者）
これは完成形ではなく、始まり。
今後のバージョンでは：
https://actu.epfl.ch/news/apertus-un-modele-de-langage-multilingue-ouvert-et/#
3ヶ月前、うちの開発チームに新しいエンジニアがやってきた。佐々木（仮名）、29歳。
経歴書を見た時点で、正直ビビった。
React、Vue、Next.js、TypeScript、Go、Rust、Docker、Kubernetes…もう何がなんだかわからない。
「また意識高い系が来たよ」
俺も同感だった。
レガシーなコードを見て「これはちょっと…」みたいな顔をする。
と提案してくる。
うぜぇ。
そんな中で何とか動くものを作ってるんだよ。
綺麗なコードなんて書いてる余裕ないんだよ。
3日で仕上げてくる。
悔しかった。
「やっぱりな。恵まれた環境にいたから、あんなことできるんだよ」
俺たちは佐々木を妬んでいた。
そう思っていた。
ところが先週、佐々木と飲みに行く機会があった。
新卒で入った会社は、まさに俺たちと同じようなSIer。Java とCOBOLでレガシーシステムの保守をやっていた。
でも、佐々木はそこで諦めなかった。
土日は技術書を読み漁り、
オンライン講座を受講し、
個人開発を続けた。
「平日は合計3時間、土日は10時間以上勉強してました。それを4年間続けました」
俺は計算した。
＝6,880時間。
「最初の転職活動は100社受けて全部落ちました。でも諦めずに勉強を続けて、2回目の転職活動でようやく今のレベルの会社に入れました」
俺は恥ずかしくなった。
佐々木を「恵まれた環境にいたから」と妬んでいたが、実際は俺たちと同じ、いやそれ以下のスタートラインから、血のにじむような努力で這い上がってきた人だった。
俺は何をしていた？
「環境が悪い」
「時間がない」
そう言い訳して、
家に帰ったらゲームして、
努力の量だ。
「今からでも遅くないですよ」
と佐々木は言った。
恥ずかしかったけど、頷いた。
毎朝1時間でもいい。変わりたい。
29歳。まだ間に合うよな？