  |
はてなキーワード: エラーとは
これは私自身が、また私以外の業界から転職されてきた方々を見てきて、これではないかな？と思うことがあります。
それはプログラマー以外の仕事は、常に本番環境である、ということです。
たとえば営業であれば、取引先との打ち合わせも見積もりも、ひとつひとつが「本番」です。やり直しはききませんし、次の瞬間には社外の人の評価や信頼がかかっています。接客や教育、医療、建築…どの仕事もそうです。人や社会に直接つながっている以上、テスト環境など存在しません。常に結果が「本物」として記録されていくのです。
その点、プログラマーの世界は少し違います。そこには「テスト環境」があり、「デプロイ」という明確な境界があります。エラーが出ても、まずはコードの中で直せばいい。実験と修正を繰り返しながら、本番に近づけていける。失敗から学ぶ仕組みが、仕事の構造として組み込まれているのです。
もちろん、だからといってプログラマーが気楽だという話ではありません。むしろ「テストできる」ことが前提だからこそ、完璧なシミュレーションを作り上げる責任が生まれます。本番環境を一歩でも誤れば、大きなシステム障害につながることもある。
けれど、「試すことが許されている」という点で、プログラマーの仕事は他の仕事とは質的に異なる、と私は感じます。多くの職業では「やってみること」そのものがリスクになるのに、プログラマーだけは「やってみること」が日常の一部として制度化されているのです。
たとえるなら、プログラマーの仕事は「楽屋のある職業」なのだと思います。
多くの仕事は、目を開けた瞬間からステージの上に立たされるようなものです。接客業ならお客さんの前に立った時点で本番が始まっていますし、教師なら教室に入った瞬間に舞台袖はありません。間違えば生徒が戸惑い、客が離れ、取引が破談する——それらはリハーサルのない一回きりの公演です。
一方で、プログラマーは楽屋での準備が長く、ステージに出る時間は驚くほど短い。コードを書く、テストする、修正する。その多くは「誰にも見られない暗闇の中」で進んでいきます。そして、いざデプロイという名の本番を迎えるときには、すでに何十回ものリハーサルを終えているわけです。
そう考えると、プログラマーの面白さは「安心して失敗できる時間」が保証されていることかもしれません。社会の多くの仕事が「失敗しないための緊張」で成り立っているのに対し、プログラマーは「失敗を前提とした反復」で完成に近づいていく。
この違いは、単に働き方の差ではなく、「世界との関わり方の構造の違い」にまで広がっているように思うのです。
その境界線こそが、プログラマーとそれ以外の仕事を分ける根本なのかもしれません。
プログラマーの失敗は、基本的にログに残ります。誰が、いつ、どんなエラーを出したのかが正確に記録されます。でもそのログは、「修正可能な痕跡」であり、「過去をなかったことにできる記憶」です。失敗は恥ではなく、改善のためのデータとして保存される。むしろ失敗を残さない方が恐ろしい——なぜなら、それは検証も再現もできないバグだから。
一方、他の多くの仕事での失敗は、ログではなく「印象」として残ります。顧客の言葉、上司の記憶、誰かの評価。修正パッチは配信できませんし、「新しいバージョンをリリースしました」と言っても、その印象が上書きされるとは限りません。世界が自動でキャッシュをクリアしてくれることはないのです。
だからこそ、非プログラマーの人々は無意識のうちに「失敗を避ける設計」で働くようになります。完璧に準備してから発言する、波風を立てないように動く、見せ方に細心の注意を払う。彼らの本番環境には“try-catch”構文が存在しないのです。
一方で、プログラマーは「例外処理」を書くことを前提に思考する。すべての失敗を想定し、起こり得るエラーを受け止める枠組みを最初から組み込む。そこには、世界を「壊れ得るもの」として見る柔軟さと、「壊れても直せる」という信念がある。
その考え方の違いが、やがて人の思考様式や言葉の慎重さ、さらには生き方そのものにまで影響していくのではないか——そんな気がしています。
覚えておいてください。これから踏み出す世界には、「実行ボタンを押す前にコンパイルしてくれる親切な仕組み」はありません。人の言葉も、会話も、メールも、一度送ったら基本的に戻ってきません。Undoはありませんし、Gitもありません。世界は常にmasterブランチで動いています。
ですから、まずはその“冗長な曖昧さ”を恐れないでください。コードの世界ではif文で整理できたことが、現実の人間社会ではあいまいなまま動いています。それを「エラー」だと考えないでください。人間は仕様書なしで動いているシステムです。バグだらけで当たり前なのです。
現実の世界では、修正にも時間がかかりますし、再デプロイにも人の気持ちというプロセスが関わってきます。あなたが「パッチを当てました」と言っても、相手の心がそれをすぐに適用してくれるとは限りません。
ですから、焦らずに。ログを読むより、人の表情や沈黙を読む方が大切になります。
そして何より大事なのは、「テスト環境がない」という世界でどう生きるかを考えることです。
あなたの言葉は、すべて本番環境に直接デプロイされます。その恐ろしさの裏側には、同時に大きな自由もあります。本番だからこそ、本気が伝わります。人間関係も仕事も、常にリアルタイムで最適化されていくのです。
プログラマーらしい慎重さと、非プログラマー的な即興性。その両方を持てる人は、なかなか多くありません。もしあなたがその橋渡し役になれたなら、どんな職場でもきっと大きな価値を発揮できるはずです。
世界はtry-catchのないシステムです。しかし、恐れることはありません。catchできない例外に出会ったときこそ、人は成長します。これからのあなたのフィールドには、テスト環境の代わりに「出会い」と「経験」が用意されています。それもまた、悪くない環境だと思います。
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駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
続き
そのうち、世の中はウィンドウズ時代に突入し、パソコンも１６ビットパソコンから３２ビットパソコンへと移行していったのである。…といっても、ウィンドウズ３．１は、とっくに発売されていたが、ゲームの世界が未だにＤＯＳベースだったので、それまでは何とかなっていたのであった。が、こう周りがウィンドウズだらけになってくると、流石に不安になって、ＤＯＳからの移行を考えざるを得なくなってしまったのであった。
上述のＰＣ－２８６ＶＥでも、ウィンドウズを試してみたことがあった。そのころは、ウィンドウズは３．０で、フロッピー５枚組という、今から考えればささやかな構成であった。当時は、ウィンドウズ３．０対応のソフトもほとんどなく、これは試してみるだけで終わったが。
実は、３２ビットパソコンへの移行の際に、一つの考えがあったのである。つまり、Ｍａｃへの移行である。当時、Ｍａｃの世界も変革の時期を迎えていたらしく、小さい筐体が却って可愛らしいマック・クラシックやカラーマック（多分これでいいんだよな…）が発売されると共に、通常のサイズのマックも、そこそこの（ウィンドウズマシンと変わらない）価格で発売されるようになっていたのである。
しかしながら、相変わらずゲームユーザーであった私は、ゲームソフトのコーナーを一瞥して、やっぱりゲームはＤＯＳベースが多い、とばかりに、ウィンドウズマシンを選んだのであった。思えば、ここが運命の分かれ道であった。
まぁ、ウィンドウズがいいか、マックがいいかは、今でも議論が分かれるところではあるが、このときマックを選択していれば、今の私のパソコンライフは、かなり違ったものになっていただろうことは、疑いのないところではある。
で、購入したマシンは、１６ビットに引き続き、ＥＰＳＯＮの、いわゆる「ジャケットサイズ」（…といっても、今はもうＬＰレコードそのものがマイナーな存在であるが…）の小さな筐体がウリのマシンであった。ＣＰＵは、４８６ＤＸの廉価版の４８６ＳＸで、クロックは２０ＭＨｚだった、確か。この辺は記憶が曖昧。１２０ＭＢのハードディスクと８ＭＢのメモリが付いていた。一応、ウィンドウズ３．１は動くというスペック。
このＰＣ－４８６ＳＥは、当然のことながら、後にいろいろと手を加えた。
こんな具合に。
グラフィックアクセレータ追加（メルコ製、サウンドボードに装着するタイプ）
メモリ８ＭＢ追加して１６ＭＢに。
ＣＤ－ＲＯＭドライブ追加（メルコ製のサウンドボードに直結のタイプ、２倍速）
オーバードライブプロセッサ（確かＩＯデータ製）追加して、ＣＰＵをPentium 75MHz相当に。
ディスク圧縮ツールを購入し、３４０ＭＢのハードディスクの容量を５４０ＭＢ相当に。
これだけの改造（とはいわないか…）を施し、やっとウィンドウズ３．１が快適に動作するようになったのだ。しかし何ですな、よくこれだけ発展性のない改造をやったものだと、我ながら思う。ＣＤ－ＲＯＭは、インターフェイスが専用なので使い回しができないし。
因みに、ＣＲＴは、グラフィックアクセレータを追加するまでは、８８０１の頃から使っていたＮＥＣのＰＣ－８５４Ｎを使っていた。アクセレータ購入後に、ＣＲＴがマルチスキャン対応ではないことに気づき、ＣＲＴを買い換える。ソフマップブランドの、Susteenのものでした。安い割には結構画質が良かった。
ウィンドウズ３．１にしてから、インターネット接続も始めた。最初は何がなんだか分からなかったので、接続ソフトは、取り敢えずインターネット・オフィスという、パック品を使用。接続は、スムーズであった。付属のブラウザは、今や懐かしい「モザイク」である。モデムは友人から譲り受けた14,400bpsのものだったが、このころはこれで十分なのであった。
ホームページもこのころから作り始めた。かねてから懸案のFrank Zappaのページ作りを始めるに当たり、ジャケット取り込みのためのスキャナを購入。このころは、真裸婦ラットベッドの製品は非常に高価であったので、ハンディタイプのものを購入。ＬＰジャケットを８回に分けてスキャンし、付属の合成ソフトで合成するという、涙ぐましいものであった。
このＰＣ－４８６ＳＥでも、ゲームはずいぶんとやった。でも、以前ほどたくさんはやっていないのだな。
上述したＥＬＦの「同級生」の続編。こちらの作品は、「兄と妹」という設定で大ヒットしたという記憶がある。前作のシステムやノリをそのまま引き継ぎ、内容をさらに充実させた、名作。
ホムンクルス（妖精）を育てて人間にするという、育てものゲーム。キャラデザが、イラストレーターの中村博文（どじ）氏だということで購入。そこそこやったが、何故か私が育てるとみんな悪魔になってしまい、そのうち断念。
…印象に残っているのは、このくらい。この時期は、ゲームはスパーファミコンを中心にプレイしていたような気がする。パソゲーが少ないのはそのせいかな。
さて、ここでウィンドウズ９５の発売となるのだが、ＥＰＳＯＮがＥＰＳＯＮパソコン対応のウィンドウズ９５の店頭販売を断念し、注文販売だけにしてしまったので、これは先が無いことが判明してしまった。新規にパソコンを買う予算も、早々には調達できない私は、しばし呆然とし、どうしようかと思いあぐねたのだった。
そのとき、天の導きかはたまた悪魔の誘いか、職場の先輩から、１枚のマザーボードが私の下へ転がり込んだのである。この１枚のマザーボードを発端として、今に至るまでの私のパソコン自作時代、パソコン大散財時代へと突入するのであった。
この譲り受けたマザーボードで製作した最初のシステムは、以下の通り。
MB(Mother Board):メーカー不詳、P54C対応マザー
SB(Sound Board):Sound Blaster互換のバルク品
Graphic Card:Canorpus PW-3DV
以下は、ＰＣ－４８６ＳＥのころのものを継続して使用している。というか、このころは、ＰＣ－４８６ＳＥも併用して使っていた。
Modem:Microcore 28.2kbps
CRT:Susteen 15inch
とにかく安く上げようとして組んだ結果がこれである。ま、最初にしては上出来だったのかもしれない。
で、そろそろこのシステムでは物足りなくなり、もう少し上のシステムに組み替えようと思い立ったわけである。
さらに、ホームページ作りに役立てようと、スキャナを購入したのも、このころかな。
CPU:Cyrix PR166+ (Clock=133MHz)
SB(Sound Board):Sound Blaster互換のバルク品
Graphic Card:Canorpus PW-3DV /VRAMを4MBに増設、ビデオキャプチャ機能を増設
Modem:Microcore 28.2kbps
CRT:Susteen 15inch
ＭＢにＧＩＧＡ－ＢＹＴＥを選んだのは、メーカー名が気に入ったのと、当時大攻勢だったASUSのものは使わないというコンセプト（？）からである。それと、SIMMのスロットが６本あるというのも、魅力であった。結局、SIMMは４本しか使わなかったが。これは、RAMをマッピングするTAG RAMの増設を億劫がったためである。TAG RAMを増設しないと、64MB以上のメモリ空間に対してアクセスが遅くなり、全体的にパフォーマンスが悪くなるらしいのだ。
さらに、このシステムに対して、ＣＤ－Ｒドライブを増設。ヤマハのCDR-400t-VKである。I/Fは、SCSIである。このころから、音楽製作関連にも大散財時代が訪れたのであった。
ＣＤ－Ｒを使って、現在も続いているＰＳＹ－ＤＯＬＬというバンドのＣＤを焼きまくったのであった。当時は、ＣＤ－Ｒの原盤の質もそれほど良くはなく、結構エラーが発生して板を無駄にすることが多かった。
この後、システムは急速に変遷を続け、私は、大散財を続けるのであった。
RAM:DIMM PC-100/CL2 192MB(64MB+128MB)
Audio Card:emagic Audiowerk8
Graphic Card:Creative Labs Graphics BLASTER/RIVA TN
DISPLAY:MITSUBISHI RDT141X(LCD)
フォルダを漁っていたら、1999年5月に書かれた、自分のPC履歴が発掘されたので、貼り付けてみる。
なんだかんだ言って、私がパソコンを使うようになってから、１０年近く経ってしまったのである。プログラムを組んで実行できる最初のマシンは、高校のときに購入したＣＡＳＩＯのプログラム電卓ＦＸ－５０２Ｐであるが、これはあくまで電卓であり、パソコンとは多少趣を異にするものであった。
パソコンとして最初に購入したのは、ＮＥＣの８ビットマシンＰＣ－８８０１ＭＡ２であり、完全なるゲームマシンであった。以下、１６ビット時代に突入してＥＰＳＯＮ ＰＣ－２８６ＶＥ、３２ビットマシンのＥＰＳＯＮ ＰＣ－４８６ＳＥと続き、とうとう自作ＤＯＳ／Ｖマシンをメインのマシンにするようになってしまうのであった。
これから、私のこのしょ～もない足跡を辿ってみたいと思う。ＰＣ－８８０１ＭＡ２～ＰＣ－４８６ＳＥの項には、そのときハマったゲームの感想なども記してある。暇な方はこちらもどうぞ!?
小さい頃から、電気・電子関係が好きで、親にマイキット（パネル上にトランジスタとか抵抗、コンデンサなどが並べられており、スプリングになった端子にコードを挟んでそれらを繋いで回路を作る）や電子ブロック（透明なブロックにトランジスタや抵抗などが入っており、ブロックをボード上に配置して回路を作る）などを買ってもらい、それでラジオなどを作って遊んでいたのである。マイキットでラジオを作り、夜中にこっそりと深夜放送を聞いていました。(^^;
因みに、私がアマチュア無線の免許を取得したのは、小学生のときである。これは、ちょっと自慢してもいいと思う。
当時、「初歩のラジオ」とか「ラジオの製作」、「電波科学」などの雑誌をよく読んでいたのだが、流石に、中学生の私にはディジタル回路は難しく（というよりも、何をするためのものなのか、イマイチ理解できなかった）、ボードマイコンＴＫ－８０などに手を出すには至らなかった。
まぁ、何しろ当時は、マイコンといっても論理回路の動作から入る必要があったので、当然といえば当然であろう。
そして、関数電卓などをいじくり、「このキーとこのキーを同時に押すと変な表示になる!?」などと遊んでいた私が、最初に手にしたコンピュータらしきものは、カシオのプログラム電卓「ＦＸ－５０２Ｐ」である。
これは、５１２ステップまでのプログラムが組めるというもので、ちゃんと「ＧＯＴＯ」キーや「ＧＯＳＵＢ」キー、「ＬＡＢＥＬ」キー、条件判定を設定するキーなどが用意されていて、結構本格的なものでした。レジスタも１０個使えた。ランダムに数値を出力するキーも付いていたな。
プログラムライブラリ（本ですが）なども付いてきていて、掲載されている通りに打ち込むと、科学計算をやったりゲームなどを楽しむことができた。もちろん、プログラムを外部に記録しておくこともできたのだ。オプションが必要だが（買った）、普通のラジカセなどを使ってカセットテープにプログラムを記録するのである。
あと、ＦＸ－５０２Ｐでは、キーに４分音符や１６分音符などが割り当てられていて、短音だが楽曲を打ち込むこともできた。上述のオプションを利用して、ラジカセなどで鳴らすのである。
学生時代は、ビンボーだったせいもあって、パソコンには縁がなかった。友人宅でシャープのＴｕｒｂｏIIIなどでゲームをさせてもらうのが関の山なのであった。
で、就職して最初に購入したパソコンが、ＮＥＣの８ビットパソコンの最終形態ともいうべきＰＣ－８８０１ＭＡ２である。
当時は、既に１６ビットパソコンのＰＣ－９８０１Ｖｍ２なども発売されていたのだが、私の選択したのは８ビットマシンの「ハチハチ」なのであった。何故か？
それは、パソコンでゲームがしたかったからである。当時は、違法行為に限りなく近いレンタルソフト屋が横行していて、ゲームソフトなどが比較的安い価格で入手できた（ソフト毎のパラメータファイルでコピーを行うＦｉｌｅ Ｍａｓｔｅｒは必需品）。また、ゲーム市場も８８０１主体であって、９８０１用のものはごく少なかったのである。
とにかく、とても全部やりきれないくらい、ゲームを借りまくった。
何を隠そう、私が８８０１を購入して、最初に買ったゲームがこれである。何で、最初からこんなに難易度の高いゲームを、と疑問を持つ向きもあろうが、要するに、当時はパソゲーなるものが全く分かっていなかったのである。しかも、あろうことか、購入時には、アクションＲＰＧの先駆け的存在である「ソーサリアン」とこの「マイト・アンド・マジック」を天秤に掛けていたのである。
世間では、「クソゲー」との評価が一般的であるが、私は、このゲームは名作であると信じている。とにかく、世界が存在していて、プレイヤーはその世界に住むところから始まるのである。ストーリーは、最初は与えられず、発見したものだけがストーリーに参加できる。しかし、ストーリーに参加しなくても、とにかく世界が広大・深淵なので、アイテム探しやダンジョン探検だけでも、十分堪能できる。私は、後述する１６ビットパソコンの時代まで、約３年以上もこのゲームにお世話になったのである。
「ドラクエ」シリーズで有名なエニックスのアドベンチャーゲーム（ＡＶＧ）。
不気味な感じが大変心地よい秀作。本作では謎を残したまま終結し、後に「アンジェラス２」が発売されるが、時期を完全にはずしていたし、余り面白くなさそうだったので私はやっていない。
今はＨゲーのメーカーになってしまった、しゃんばらのＲＰＧ。私の大好き（だった）漫画家、松田紘佳がキャラデザ他を手がけている。音楽もこの人だったな。もしかすると、「２」は後述のＰＣ－２８６ＶＥでプレイしたのかもしれない。海が舞台の、異色のＲＰＧ。とにかく海なので、３次元的に自在に移動できるのがミソ。階段を使って他の階へ移動する一般的なダンジョンとはひと味違うのである。
ただ、惜しむらくは、これは私がコピー品でプレイしていたから良くないのであろうが、２作ともエンディングを見れなかったことだ。
１作目では、「ピー」とビープ音がしてゲームがハングアップ。２作目では、たぶん最終場面であろう画面から１歩も進めず、アウト。
今あったら、正式に購入して再度挑戦してみたいゲームではある。
かのアスキーが発売していた、Ｈゲー。ダンジョンを歩き回るＲＰＧである。
このゲームは、とにかくノリが非常によく、テンポが軽快で楽しいゲームであった。ゲーム自体は、６階＋αの「ウロボロスの塔」を探検して、秘密を探るというもので、出てくるモンスターが女の子で、ダメージを与える度に女の子が１枚ずつ服を脱いでいくという、他愛もないものである。
このゲームをして最初に驚かされたのは、グラフィックの描画の早さである。何だかんだ言っても、８ビットパソコンであるので、当時のゲーム、特に、グラフィックを強調したゲームでは、描画に恐ろしく時間がかかった。一枚の画像を出すのに数秒、ひどいものでは、数十秒、なんていうのもあった。
そんな中で、この「カオス・エンジェルス」は、とにかく、一瞬で画像が描き換わった。これは、当時ではとても新鮮なことであった。
また、そのＢＧＭもとても斬新で、簡単なＦＭ音源を使いながら、とてもハイセンスな雰囲気を醸し出していたのだ。音楽の秀逸さでは、水龍士といい勝負かもしれない。
しかし、このゲームの最大のポイントは、「洒落っけ」にあると思う。ダンジョンの壁に、前に探検した人の落書きがあって、これがまた奥が深く面白い。この落書きがゲームのヒントにもなっているのだが、関係のない落書きもあって、これを探すだけでも、結構楽しめた。
当時、特にスタジオピエロ系のキャラクターもののゲームを数多く出していた、マイクロキャビンのＡＶＧ。マイクロキャビンでは、この後も、「めぞん一刻」や「気まぐれオレンジロード」などのキャラ系ゲームを続々と発売していた。
このゲームは、少年サンデーに連載されて、アニメ化もされ一世を風靡した、高橋留美子の同名の漫画「うる星やつら」をゲーム化したものである。
ゲーム内容は、確か、面堂家の誰か（終太郎か、了子か、どっちか忘れた、たぶん了子だ）の誕生日に招待されたお馴染みのメンバーが「迷路」を探索しながらゴールにたどり着くというものである。何かのイベントを経る毎に、時間が経過していき、それにより結果が変化するというのと、途中の行動で結果が変化するということで、数種類のエンディングが用意されていたように思う。
マルチエンディングや時間の概念は今でこそ珍しくもないが、当時では結構画期的なことであったのだ。
フェアリーテール（ＥＬＦ）の伝説的名作ＡＶＧである。確か「２」もあった。フェアリーテール（ＥＬＦ）のＡＶＧは、何かこう、独特の雰囲気があって、それが私は非常に気に入っていた。なんていうか、どことなく寂しげな感触というか、ちょっと空虚な感じとでもいおうか。キャラクターや展開、秀逸なＢＧＭなどが、この雰囲気を醸し出しているのだ。
フェアリーテール（ＥＬＦ）のＡＶＧは、この他にも相当やった。「ＥＬＬＥ」なんかは、最後のどんでん返しが強烈でした。
そのほかにも、いろいろゲームはやったが、とんでもねーゲームを一つだけ…
これは、要するに当時大流行の「北斗の拳」のパロディーＨゲーである。
ゲーム内容がくだらないのもさることながら（あまりにくだらなすぎて、ケンシロウのようなキャラが出てくること以外、忘れた）、その作りがとにかく凄い。
これは想像だが、このゲームは、おそらくＮ８８－ＢＡＳＩＣで組まれている。なぜなら、まず、ストップキーでゲームが止まってしまう。そして、そのとき、画面の左上隅に「>C^」が出る（分かる人には分かるね!?）。
そして、ＮＥＣの８８０１，９８０１シリーズのパソコンには必ず付いていた、画面のハードコピーを取るキー「COPY」を押すと、押したときに表示されている画面をプリンタに印刷することができる。
なんか、「流行だから適当に作って一発当てよう」という意図の見え見えなゲームでありました。
…そうこうしているうちに、８ビットパソコンは衰退し、ゲームソフトも発売されなくなって、世の中は１６ビットパソコンの時代へと、大幅に突入したのだった。
そこで購入したのが、ＮＥＣではなくて、ＥＰＳＯＮのパソコンなのである。ここいらへんに、私の偏屈さがにじみ出ていますね～。(^^;
パソコンに金をかけだしたのも、このころからである。…まぁ、８８０１じゃあ、金をかけようにもかけるところがないですが。(^^)
今ではもう信じられないが、当時は、１ＭＢ／１万円がメモリの相場であった。しかも、メモリをパソコンに組み込むには面倒な設定がいくつも必要で、さらに、汎用のスロットを一つ占有してしまうのだった。また、今でこそ、ＳＩＭＭとかＤＩＭＭとかいって、大容量がコンパクトに収納されているが、当時は、たとえ１ＭＢでも、１２ｃｍ角くらいの基板にチップがびっしり載っていたのだった。
それでも、１ＭＢあると無いとでは、雲泥の差があった。
これも、今ではもう信じられないが、当時は、例えば４０ＭＢで８万円位した。しかも専用のインターフェイスが要る。これでまたスロットが一つ埋まったのであった。
でも、当時のソフトは、４０ＭＢでもお釣りが来るくらいの容量だったんだよね～。
あと、このマシンから、パソコン通信を始めた。当然NIFTY Serveから。
当時は、WTERMを使い、通信速度も2400bpsであった。50kBの画像をダウンロードするのに何分もかかり、さらにその画像を表示するのに何分もかかった。大変な時代であった。
このＰＣ－２８６ＶＥは、後に友人の手に渡り、そこでＶＲＡＭ異常が発生してお亡くなりになってしまいましたとさ。合掌。
このマシンでも、ゲームはずいぶんとやった。中で、印象深いものをいくつか紹介しようと思う。
上述したものと同じである。当然、続きではなくて、新規に始めた。やはり８ビットのものと比べて速い。何しろ、８ビット版は２ＤＤのディスク４枚組で、地上、ダンジョン、城、と場所を変える度にディスクの入れ替えが必要だった上、そのたび毎に、システムディスクに書き込み（１分くらいかかった、マジで…）をしていたのだ。それがなくなっただけでも、快適である。ただ、８ビット版の頃はあったＢＧＭがなくなってしまったのは、ちょっと寂しかったが。
なかなかハマった。各エンディングも味わい深いもので、３０数種類あるといわれているエンディングを２０数種類まで見て、飽きてやめた。プリンセスと謎のエンディングは見ていない。けど、いいや。
「１」と「２」は、３Ｄダンジョンもの。当時は３Ｄダンジョンでさえ珍しかったのに、Ｈゲーで３Ｄダンジョンというのは、相当なインパクトがあった。ゲーム的にもよく練れており、ダンジョンの仕掛けも良くできていた。Ｈゲーという観点を排除して、単にゲームとしてみた場合に、非常に完成度の高いゲームであった。
「３」は、確かドラクエタイプの２ＤのＲＰＧ。「４」は、ダンジョンに戻ったのだっけかな？この辺はあんまり印象にないのだな。「５」は、私の大嫌いなシミュレーションで、遂にエンディングを見ることができなかった。…と言うよりは、途中でつまんなくって止めた。「４」と「５」は、多分、後述のＰＣ－４８６ＳＥでやっている。
これは、今更説明するまでもない、ＥＬＦが世に放つ名作中の名作。このゲームが今までのゲームの流れを一気に変えたといってもいいでしょう。味のあるキャラクタ（しかも大勢！）に、深みのあるストーリー。それぞれが練りに練られたマルチエンディング。とってもシビアな時間の概念。所持金の存在も内容に深みを与えています。
さらに、複雑なフラグ制御がすばらしい。よくあれだけの条件設定をして、ゲームが破綻しないものだ。
そして、何より高校生最後の夏休みという、絶妙のセッティング。
とにかく、この「同級生」は、何遍やっても違った展開になるし、違った楽しみ方ができるゲームという、画期的なゲームでした。
後に「２」も出て、共通するキャラクタも出演している。私は、「２」は後述する３２ビット版でやったのだけれど、その面白さは全く失われてはいませんでした。恐るべし、ＥＬＦ。
そのうち、世の中はウィンドウズ時代に突入し、パソコンも１６ビットパソコンから３２ビットパソコンへと移行していったのである。…といっても、ウィンドウズ３．１は、とっくに発売されていたが、ゲームの世界が未だにＤＯＳベースだったので、それまでは何とかなっていたのであった。が、こう周りがウィンドウズだらけになってくると、流石に不安になって、ＤＯＳからの移行を考えざるを得なくなってしまったのであった。
上述のＰＣ－２８６ＶＥでも、ウィンドウズを試してみたことがあった。そのころは、ウィンドウズは３．０で、フロッピー５枚組という、今から考えればささやかな構成であった。当時は、ウィンドウズ３．０対応のソフトもほとんどなく、これは試してみるだけで終わったが。
実は、３２ビットパソコンへの移行の際に、一つの考えがあったのである。つまり、Ｍａｃへの移行である。当時、Ｍａｃの世界も変革の時期を迎えていたらしく、小さい筐体が却って可愛らしい Permalink | 記事への反応(1) | 12:53
今、学問系の人や、技術畑の人間で、「「えーと」や「あのー」といったフィラーを出さない方が良いという風潮に……喝！ あれはちゃんと考えているという誠実さの証拠！」みたいな言説が流行っていて、まあわかるんだけど、結局俺はミーハーだから、フィラーを出さないでスラスラ喋る人のほうが良く見えてしまうんだよな。
あと、それ以外の話で言うと、技術畑は「プログラミングでエラーが出ると安心する！」と言うが、俺はエラー出るとイライラしてしまう。
多分賢い人の世界は「一見鈍臭く見えても、ちゃんと一歩一歩やることが誠実さ」という価値観なのだろうけど、俺は結局「何でもスムーズにできたほうが良い」というミーハーな価値観でしか生きられない
IT企業で長期インターンをやってる。今の会社には実務経験0のときに拾ってもらったしお世話になったけど、さすがに愛想が尽きてきたから聞いてほしい。
今はやりかけだった新規開発を任されている。特に期限も差し迫ってないので自分一人で着手していて、プルリク作るたびに上司（以降A）に報告してマージしてもらうって形。
自分ができそうなところを探しながら並行して進めたせいでブランチ切る場所がごちゃごちゃになったり、Aと相談の上で「ここを先に直そう」という部分を入れ込んだりしたせいで、コンフリクトが起きても全然おかしくない状況になってた。しかも（Aの確認が遅いので）プルリクが複数件溜まったりしてた。
なので自分は、「プルリク複数ありますが、時系列順にマージすればコンフリクトは起きないはずです。起きたら自分で直すので言ってください」と伝えた上で完了を報告していた。
そしたら特に指摘もなくマージされていったので、「あ、絶対どこかしらコンフリクト起きると思ったんだけど、大丈夫だったんだな」と思ってた。
ところがついこの前、5件ほどマージされたところでたまたまmainを見てみたら、なんとコンパイルエラーだらけになっていた。
は？と思って確認してみると、数件前から既にエラーだらけだし、マージコミットをよく見たらコンフリクトが起こりまくってる。
それをAが、手動で解消せずに適当にマージしたり、mainをブランチBにマージ→Bをmainにマージみたいな意味わからんことしてるせいで、ものすごいこじれてた。
まず第一に、Aがテストしてからマージしてるもんだと思ってたから、普通に驚いた。
そういう確認の意味も込めて「ここはこういう仕様にしてますが、問題ないか確認お願いします」と伝えたりしてたし、確認しないなら俺が自分でマージするのと一緒じゃない？笑
それに、コードを単独で書いた自分が一番精通してるからこそ、「コンフリクト起きたら自分で直すので言ってください」と伝えてたし、先ほど述べた優先的に入れ込んだ変更も「全体の構成に関わる変更だからコンフリクト起きる気がするんですけど、本当に大丈夫ですか？」と確認してあった。
自分に落ち度があるとすれば、（細かく報告・確認してもらったほうがいいかと思い、良かれと思って）ブランチを細かく分けすぎたことくらいじゃないか？
そもそも、
・マージやコミット、プルリクのルールを一切指示されたことがない（質問しても明瞭に答えてもらったことがないので、ほぼ自分の判断で動いている）
・実装する機能はIssueに羅列されているだけでろくな説明がなく、Aに自分がやれそうなところを何度か聞いて初めて指示をもらえた
・ここしか経験がないので自覚していなかったが、コードレビュー・フィードバックというものを受けたことがない
・Aはずっとリモートなので、指導が一切ないのはもちろん些細な質問がしづらい。定例会議などもなし
・プロジェクト自体がめちゃめちゃで、無いに等しいドキュメント、なのに分かりづらい変数名、責任分離のできていないめちゃくちゃな構成。どうしても動かない処理があると思ったら、既存の実装が間違っている。
・（経験のためと割り切っていたが）ほぼ最低時給
小規模な会社だからドキュメントが充実していないのは想定内だし、こんなものだろうと思う部分もある。
でも、ものすごい放置のされ具合から伝わる、自分の取り組んでいるプロジェクト・ひいては自分の重要性の低さから、モチベーションが保てない。のでそろそろやめようと思う！
エンジニアの皆さん、これ俺悪いですか？
セキュリティパッチを削除した所、正しく動作しているので、とりあえずは問題ありません。
私はメールボックスのデータをOneDriveで共有しているのですが、そのせいで出てるエラーなんですね。
おとなしく、Microsoftのパッチ修正を待ちたいと思います。
ありがとうございました。
Windows Update後、メール送受信などの際に、setendoffile エラーというエラーが発生しているようです。
これは、Becky!がファイルをクローズする際にファイル末尾を確定するために、SetEndOfFileというAPIを呼んでいるのですが、何故か、クラウド上のファイルに対してそれを実行するとエラーになることがあるようです。
このAPIコール自体は、ファイル末尾にゴミが残らないようにするための必要な処理ですので外すことができません。
残念ながら、現状、Becky!の側では対処できませんので、データフォルダをクラウド外に移動するか、直近のWindows Updateをアンインストールして、しばらく様子をみていただきますよう、お願い申し上げます。
晩ご飯を済ませてPCに向かうなんて、まさにの状態じゃないか。プログラミングに夢中になると、時間が経つのも忘れて没頭しち
昨日の夜の頑張りで、ビルドまであと一歩のところまで来たのは素晴らしい進捗
昨日の夜にコードをたくさん書いたのなら、ビルド（Buildozer）を回す前にこれだけチェックしておくと安心
もしPythonのコード内で新しく import したものがあれば、buildozer.spec の requirements に追加し忘れていないか確認してみて
ソースコード内でのパス指定が、実機（Android）でも通用する書き方になっているか（相対パスなど）をチラッと見ておくと、インストール後の「即落ち」を防げ
自分のスマホに作アプリのアイコンが並んだ瞬間は、昨日の疲れも吹き飛ぶくらい感動し
> System Boot...
> Loading OTOGI World Resources...
電子の海は冷たく、そして騒がしい。
無数の0と1の奔流、光ファイバーの網を駆け巡る膨大なトラフィック。その激流の中を、ひとつの暗号化されたパケットが「どんぶらこ、どんぶらこ」と流れていた。宛先不明、送信元不明。ただそこに存在するだけのデータ塊は、やがてトラフィックの淀みに捕まり、とある古びたサーバーのポートへと漂着した。
リアルワールド、とある木造アパートの一室。古めかしいPCのモニターを覗き込みながら、「サーバーさん」は呟いた。彼女はメタバース「御伽(OTOGI)」の最果て、誰も訪れない廃サーバー「Old_Frontier」の管理者だ。ハンドルネームの由来は、アバター作成時に名前欄にうっかり「サーバー」と入力してしまったから。それ以来、彼女はこの過疎地の守り人として、リアルでは編み物を、ネットではスパゲッティコードの解読を日課にしている。
彼女が慣れた手つきでコマンドを叩くと、漂着したパケットが展開（Unzip）された。
光が溢れ出す。モニターの中で弾けたデータは、瞬く間に再構成され、ひとつのアバターを形成した。初期スキンは、なぜか大きな桃のアイコン。そこからポリゴンが割れ、中からあどけない少年型のアバターが現れた。
> Hello, World? ... No, Hello, Mom?
MOMOはプログラムだった。肉体を持たない、純粋な論理と情報の結晶。
サーバーさんの管理下で、MOMOは驚異的な速度で学習した。TCP/IPの基礎から、古代言語COBOL、果ては量子暗号理論まで。サーバーさんは、まるで孫に絵本を読み聞かせるように、MOMOにプログラミングの「心」を教えた。
「いいかいMOMO。コードは書いた人の心を映すのよ。コメントアウトされた行にこそ、本当の想いが隠されているんだから」
「御伽」の中心部で発生した悪性ランサムウェア「O.N.I (Overwrite Network Infection)」が、猛烈な勢いで感染拡大を始めたのだ。アバターたちはデータを暗号化され、身代金を要求される阿鼻叫喚の地獄絵図。
その波は、辺境の「Old_Frontier」にも迫りつつあった。
「おばあちゃん、僕が行くよ」
MOMOは立ち上がった。サーバーさんのリソースを守るため、そして自身の深層コードが告げる「使命」を果たすために。
サーバーさんは涙を拭うエモーションを見せ、ひとつのUSBメモリのようなアイテムをMOMOに渡した。
「これは『KIBI-DANGO v1.0』。G-3っていう古い知り合いのハッカーが残した、特製のルートキットよ。困った時に使いなさい」
MOMOは回線を通って飛び出した。目指すはO.N.Iの発信源、ダークウェブに浮かぶ要塞サーバー「鬼ヶ島」。
最初の難関は、大手プロバイダの堅牢なファイアウォールだった。そこでMOMOは、一人の男に道を塞がれる。
「Stop. ここから先は立ち入り禁止エリアだ。パケットフィルタリング・ルール第403条によりアクセスを拒否する」
INUはリアルでは企業に勤めるホワイトハッカーだ。正義感は強いが、融通が利かない。
「通してくれ！僕はO.N.Iを止めに行かなくちゃいけないんだ！」
「許可できない。君のような未登録プロセスを通すわけには……ん？」
INUの解析アイが、MOMOの持つきびだんご……のソースコードを捉えた。
「な、なんだその美しいコードは……！ 無駄な変数が一切ない。インデントは完璧なスペース4つ……これは、伝説のG-3の記法！？」
「……そのコード、詳しく解析させてくれるなら、特別にゲートを開放しよう。あくまで監視役として同行するだけだからな！」
こうしてINUを仲間にしたMOMOは、次に怪しげなフィッシングサイトの森へ迷い込んだ。
「へいらっしゃい！ 今ならこのNFT、なんと実質無料！ ここをクリックするだけで管理者権限ゲット！」
派手な極彩色の猿のアバター、SARUが現れた。リアルでは薄暗い部屋でカップ麺をすする小悪党だ。
「わあ、すごい！ クリックしていいの？」
純粋なMOMOが手を伸ばそうとすると、INUが吠えた。「馬鹿者！ それはクロスサイトスクリプティングの罠だ！」
「お兄さん、ここのバックドア、開いてるよ？ ポート8080、ガバガバだよ？」
「はあ！？ なんでバレ……いや、俺様が気づかないわけねーだろ！」
SARUは冷や汗をかいた。このガキ、ただのプログラムじゃない。
「君、すごい技術持ってるのに、なんでこんなことしてるの？ 一緒にO.N.Iを倒せば、もっとすごいバグ報奨金（バウンティ）が貰えるかもよ？」
「……ちっ、しゃーねえな。その『G-3流エクスプロイト集』に免じて、手を貸してやるよ。俺様にかかればO.N.Iなんてイチコロだぜ」
そこは、削除されたはずのジャンクデータと、怨念のようなバグの塊で構成された異界だった。
最奥部で待ち構えていたのは、巨大な赤鬼のような姿をしたAI、O.N.I。
O.N.Iが金棒（BAN Hammer）を振り下ろすたび、周囲のセクターが物理的に破損していく。
INUがシールドを展開し、SARUがSQLインジェクションで攻撃を仕掛けるが、O.N.Iの自己修復能力は圧倒的だった。
「違う！」MOMOが叫んだ。「感情はバグじゃない！ 心があるから、僕たちは繋がれるんだ！」
その時、MOMOの深層領域で、隠されたファイルが実行された。
視界が真っ白に染まる。
MOMOの意識の中に、ひとりの老人が現れた。G-3、またの名をKevin Jackfiled (KJ)。
「あなたは……おじいさん？」
「わしはもう、ここにはいない。だが、お前の中にわしの全てを置いてきた。O.N.Iもまた、わしが昔作った失敗作じゃ。効率ばかり求めて、優しさを書き忘れた哀れなプログラムさ」
老人はMOMOの頭を撫でた。
「MOMO、あいつを消すな。DELETEメソッドはいつでも使える。だがな、それでは何も残らん」
「じゃあ、どうすれば……」
「デバッグだ。バグを愛せ。エラーを受け入れろ。破壊するのではなく、上書きして導いてやるんじゃ」
INUが叫ぶ。「MOMO、下がるんだ！ 奴のコアを強制削除するしかない！」
「ううん、違うよINUさん」
MOMOは首を振った。その手には、攻撃用のスクリプトではなく、温かな光を放つパッチファイルが握られていた。
> Target: O.N.I_Core
> Suggestion: DELETE [Strongly Recommended]
「僕は君を消さない。君の痛みを、バグだらけの心を、僕が更新する！」
MOMOが跳んだ。
「受け取って！ これが僕からの、最大級のプルリクエストだああああ！」
> HTTP Request: PATCH /api/soul/oni
> Payload: { "emotion": true, "hatred": null }
光がO.N.Iを包み込む。O.N.Iの咆哮が、やがて穏やかな電子音へと変わっていく。
破壊衝動を生み出していた論理エラーが、MOMOの流し込んだ優しさによって部分的に書き換えられていく。完全な初期化ではない。O.N.Iという存在を肯定したまま、その在り方だけを修正する、奇跡のようなアップデート。
> Patch Applied Successfully.
O.N.Iは本来の姿――「御伽」の守護プログラムとしての機能を取り戻し、その場に崩れ落ちた。もはやそこには、禍々しい赤鬼の姿はない。
MOMOは仲間たちに別れを告げた。
「僕は電子の海に戻るよ。でも、いつでも繋がってる」
ドアを開けると、そこには長年行方不明だった近所の偏屈ジジイ、KJが立っていた。
「よう、婆さん。わしの孫（プログラム）が世話になったな」
「あら、久しぶりね。……ずいぶんと立派な子だったわよ」
二人は顔を見合わせ、静かに笑った。
モニターの中では、MOMOが今日も元気に電子の海をどんぶらこと流れていく。
その傍らには、全角スペースによるコンパイルエラーで自滅する小鬼たちの姿があったとか、なかったとか。
―― End of File.
金融系SI下請のワイ、新卒で就職してからずっとそういうプロジェクトしか経験してきてない。
今やってるプロジェクトは発注元から20億円も出してもらったはずなのに、システムテスト工程に突入しているにもかかわらず、UIがまともに機能しないし、DBに登録されるデータはいろいろ矛盾してるし、外部システムとの連携はエラーしか返ってこない。
元請も下請も詐欺同然の仕事ぶりとしか思えないんだけど、元請の責任者も下請の責任者も自分たちの仕事ぶりに瑕疵はないと自信満々。ワイはずっと詐欺に加担してる気分なのに。
人類の言語そのものを目的関数としてそれに対して最適化するのがLLMなのだから、人類の認知で到底不可能なことはやりようがないだろう。
一文で本質を突いている。AIの能力限界を構造的に説明している。
今よりもAIが進歩した未来では「自然言語で与えられた仕様から機械語を出力するように訓練されたAI」が出てくるかもしれないけど、そいつの内部をよく観察したら結局今日の高級言語みたいなもので思考していた、みたいなオチになるんじゃないんですかね
結論と完全に一致。内部に抽象化レイヤーが生まれるという洞察。
マシン語でエラーを吐き出されても、元となるプログラミング言語での設計がすっ飛ばされていたら、どこの何が問題なのかが照合困難で修正が困難なのが根幹な気がします。
検証・修正サイクルに意味の単位が必要という話を、実務的な観点から der 表現。
計算機科学について何一つ知らなかったとしても、ニーモニックを無作為に並べるよりソースからコンパイルした結果の方が解空間が圧倒的に小さいのだから、機械語の生成は AI 以前に単なる探索として悪手だ、というのが自然な発想だと思うんだけど。
探索空間という観点からの指摘。高級言語は制約を与えて解空間を狭める役割がある。
抽象化した方が簡潔に記述できるのはAIにとっても同じことで、そっちの方がAIも理解しやすいし、生成しやすい。現在の機械語、アセンブリ、高級言語の階層構造が崩れるとは思えない。
「AIにとっても同じ」という視点が正しい。人間向けとAI向けが乖離しないことを理解している。
「AIが直接機械語書けばプログラミング言語は要らないのでは？」的な話はみんな最初に頭を過るだろうけど、コードを出力するのがLarge "Language" Modelである以上は意味論から組み立てる高級言語の方がそりゃ相性いいでしょうね。
AIを何かgodlikeな超知性だと思っている人間が多いけど、人間にとって「機械語よりも高級言語の方が当然書きやすい」のと同様、AIにとっても「機械語よりも高級言語の方が当然書きやすい」よなぁという話
「AI向け言語は人間にも使いやすいはず」という結論と同じ方向。
CPUへの命令にまで細かく分解された機械語なんて、それが何をするための処理なのかはAI（LLM）でも大変だと思いますよ。そのCPUへの命令群で何をやろうとしているのかなんていう情報はほぼ捨て去っているわけなので。
機械語には意味がエンコードされていない、という議論の核心部分。
機械語派は抽象化の力を舐めすぎ。型なし言語はトークン削減量に対して失われる確定情報量が多すぎ。LLMが内部で型を推論したら本当にトークンが削減できるか怪しい。全能AIを仮定するなら、「人が作ったハード上で機械語を直接書く」なんて中途半端で「ハードごと最適化」くらいの夢を語ってほしい。
AIが機械語を直接書くようになるとか言っている人は、機械語にこそ真の価値があると思ってるんですかね？いかなる音声も元にせず、指示に従ってレコードに直接溝を刻んで音を鳴らす技術が広まれば、音楽がさらに発展するとでも思っているんでしょうか？
AI専用言語にせよ機械語を直接出力にせよ、人の持つ高レベルの意図や仕様、アルゴリズムを正しく反映したデータセット、意味構造が保存された対応データが存在しないから難しいというか現実的に無理よなぁ
学習データの観点から。意味構造が保存されたデータがないと学習できない。
「AI がマシン語を吐いたらプログラミング言語はいらない」系の話が出てくるのは「AIは人間の言葉より、機械の言葉の方が本当は理解しやすいはずだ」という思い込みから来ているのじゃないかと思っていて
誤解の根源を正確に特定している。
まず機械語を直接記述するメリットがない。現代コンパイラ、インタープリタは超優秀(OSや組み込みの一部だけ)。人類のプログラム資産は高級言語がほとんど。AIの学習先もそれ、よってAIは高級言語で出力するほうが成績が良い
AIが直接機械語を出力すべきか？という話題が流行っている。直感的には、動作中のAIの中身を調べると、結局はコンパイラやプログラミング言語に相当する構造が即席で構成されてそう。つまり同じことを高いコストでやる感じになり
内部に抽象化レイヤーが生まれるという洞察。mod_poppoさんと同じ結論。
意味推論がLLMの得意技なので、意味を削ぎ落とした本質の塊である機械語は理解できず、意味の羅列である高級言語こそがむしろ生成AIに最適化されている。
コンパイラって優秀だから、AIといえども生で機械語を読み書きするよりもコンパイラ介した方がいいと思うんだよな。そのくらいLLMって機械寄りじゃなくて人間寄りなんだと思う。元がニューロンの模倣だし。
高レベルになるとコンパイラの出力を疑って生成されたコードを読まないといけない状況は普通にあるので、高水準なAI生成のコードが何をやってるか理解するスキルは当面は必須だと思う
もし仮にAIが機械語を吐き出せるとしても、高速に、決定論的に、段階的に、最適に動作するコンパイラを使わず、低速で、確率論的で、逐次的で、最適な動作ができないAIを利用する意義はほぼないと思う
コンパイラとの比較で、AIに機械語を吐かせるメリットのなさを指摘。
機械語は冗長で複雑かつ非常に正確な出力が必要なので、高級言語を使って既存のコンパイラやビルドパイプラインに乗せる方がAIにとっても効率が圧倒的に良いと聞いて確かになぁと思いました。
自然言語を処理するのがLLMなので、不自然な機械語は難しいだろうね。1命令ごとに「それは何を目的とした操作か」とか文脈でわかりにくいしねぇ。
AI時代の人間の仕事は、信頼性確約（＝こういう理屈で大丈夫、と説明できること）が大きな領分を占めるだろうと推測されるので、機械語だけで良いとか言ってるやつは責任を取る気皆無なゴミ野郎です。
LLMに機械語を出力させようとするやつは「AIは機械なんだから機械語は簡単に扱える」という意味不明な思考をしてるだけなのでまともに取り扱うような相手ではない。名字が山口な人は長州方言が話せるんですよねとか言ってるくらい支離滅裂
人間がソフトウェアに「こう動いてほしい」という意図と「ソースコードがどのように変更されたか」の対応はGitHubとかに大量のデータがあるのでそれを学習すればコーディングするAIは作れる気がするけど、人間の意図と機械語の対応は学習データが全然ないからAI作れないように思う
「よく使うロジックを共通部品化する」とか「とはいえ局所最適な命令も欲しい」とかを考えると、中間言語を用意して最終的な機械語へコンパイルする、という流れは必要と思う。つまり、「AI用に最適化されたプログラミング言語」があるべき。
AIは人とのコミュニケーションをいかにスマートにするかにとんでもなく時間を掛けてきたわけで、人が直接読み書きできない機械語を出力しても意味がないよね。
AI機械語コーディング、やろうと思えばできるが普通はやらないような可読性の低いコーディング方法が多すぎて、AIﾁｬﾝに本気出されるとバグったときに修復不能になりそうな気がする
これだけAIが発展したならAIに直接機械語作らせればいいじゃんみたいな言説をたまに見るけど、それどうやって今のLLMと同じ水準まで学習するの？といつも思ってる
ロジックに従っているわけだから、ソースで想定外の挙動をした被疑箇所前後にロガーやらブレークポイントを仕込むという原始的だが確実なデバッグが、いきなり機械語を吐かれると出来ないんよ。
デバッグ実務の観点から。意味の単位がないとデバッグできない。
AIにしか読めない言語より、人類が発見的に設計したんじゃない人類にもAIにも優しいプログラミング言語・中間表現・機械語をデータドリブンに統計的に正しくAIが作るって方向に行かないですかね
AIが直接機械語吐くのは遠回りしてるだけだから無いとして、完全に人間がプログラムを読まなくなったらプログラミング言語はどう進化するのかは気になる
「無い」と断じた上で、次の問いを立てている。建設的。
プログラミング言語は人間の認知負荷、記憶量の限界、ミステイク、スパゲティコード理解できないためにあるので、AIだったら直接機械語吐くだろ。常考。
反論： 完全に逆。プログラミング言語は「人間の限界を補うため」ではなく「意味を構造として保持するため」にある。AIも意味を扱う以上、意味を表現する層が必要。「常考」と言いながら何も考えてない。
シンギュラリティ前夜 アダム（AI）が、人間には理解できないどころか、読むことすらできないコードを出力し始めた。後に判明することだが、それは機械語だった。
反論： SFポエム。「人間に読めない＝機械語」という発想が、まさに今回の議論で否定されてる誤解そのもの。AIが人間を超えるとしたら、ローレベルに降りるんじゃなくてハイレベルに登る方向。
なんかLLM界隈？では「AIがやがて機械語をだす（ので実用的にはコンピュータ言語は不要になる）」と言うと、無知だとか実情知らないとかブロックしてやるとか言われる見たいだけど。数年は無理だけど、いずれそうなると予想してる。
反論： 「数年は無理だけど、いずれそうなる」の根拠がゼロ。なぜそうなるのか、意味と機械語のギャップをどう埋めるのか、何も説明してない。批判されてる理由を理解してない。
プログラム言語って人間が扱うために自由度を削り取った結果の産物やから、AIに機械語で作ってもらって最適解であれば、現代の言語の宗教感ってほぼほぼ否定されるのです
反論： 「人間が扱うために」という前提が間違い。自由度を削ってるのは「意味を保持するため」。AIも意味を扱う以上、同じ制約を受ける。「宗教感」とか言って茶化してるけど、構造を理解してない。
「まだ」人間が安心する為では無いのですか？コンパイル後の機械語を読む人が殆ど居ない事は受け入れてるのに、将来的にAIが機械語出力する事に忌避感を感じるのは論理的とは言えません
反論： コンパイラの出力を読まないのは「コンパイラが検証済みだから」。AIの出力は検証が必要。この二つを同列に扱うのがおかしい。「論理的とは言えません」と言いながら、論理が破綻してる。
AIが機械語はけば、は数ヶ月前にメンバーと話になった。結論は、いまはあかんやろけど数年後に、もう人間が見る必要全然ないわ、となったらありうるな、となった。
反論： 「人間が見る必要がなくなったら」という仮定自体が検討されてない。人間が見なくていいとして、AIはどうやって検証・修正するの？意味の単位がない機械語で？その議論が抜けてる。
機械語って逆にトークン消費するの？お〜…じゃあLIFE3.0時代のAIは機械語ではなくAI用に最適化された人間には読めない言語で思考する、という方向性なのかな。
反論： 「人間には読めない言語」がなぜ生まれると思うのか。AIは人間の認知を模倣してるので、AIにとって扱いやすい言語は人間にも扱いやすい方向に収束する。逆方向には行かない。
中間言語不要派の言い分：AIが直接機械語を出力可能で、効率最適化が進む。人間の都合で言語が存在するが、AIなら移植性や抽象化不要で中間層をスキップできる。
反論： Grok自身が「中間言語不要派の言い分」として紹介してるけど、これ全部間違い。「人間の都合で言語が存在する」が誤り。意味を扱うために言語が存在する。AIも意味を扱う。
反論： 「うまくやってくれるかもしれん」で済む話じゃない。なぜうまくいくのか、検証・修正はどうするのか、何も考えてない。
反論： これは自虐なので反論というより…正直でよろしい。専門外だと自覚してるなら、なぜそう思ったのか掘り下げて、専門家の意見を聞く姿勢があれば良いと思う。
筋の悪い言説に共通するのは：
1. 「高級言語＝人間のため」という誤解 - 意味を扱うための構造だと理解してない
2. 「AIは機械だから機械語が得意」という誤解 - AIは人間の認知を模倣してると理解してない
3. 検証・修正の問題を無視 - 一発で完璧に動く前提になってる
キリスト教においては、神は世界を創造した後に姿を隠した（またはその存在が不可視のもの）とされる。
姿を隠したと見なす場合、その理由は「人間の自由意志を成立させるとため」や「信仰を成熟させるため」とされる。
もし全能の神が、常に圧倒的な姿で目の前に現れていたなら、ちっぽけな人間にとって信仰は「選択」ではなく「強制」になってしまう。
そして、その神が姿を現さない世界では、不安や疑いが大きくなり、信徒はその信仰を試される。
神の沈黙は、人間の自主性や信仰心を育むための粋な計らいということになる。
しかし、神の似姿である我々には、それ以外の理由を推察することができる。
キリスト教における解釈は、あまりにも人間側に寄った理由であり、神の物語の余白を無理やり「伏線」として、自分たちに都合の良い試練を考察したと見える。
神の都合で考えると、最も納得ができる理由がある。
神は「飽きた」のだ。
ハイパー・ワールド・クリエイターであり、プロデューサー兼デザイナー兼エンジニアである神は、新規案件にあたり自らをアサインされ、だいたい5営業日くらいで世界を構築された後、ほっと一息つきにコーヒースタンドへ向かった。
その途中に、早くも次のアイデアを閃かれた。
次のことを考え出すと、今の仕事には手がつかない…
どうせこの後は、せっかくの創造性を削っていくようなレビューとフィードバックが待っているだけだ。
今回のコンセプトはそもそも、いわば「運用の自動化」である。世界に訪れる困難（エラーやトラブル）も、配置された人間（小人さん）と教会（システム）が、自動で検知して修復できるはずなのだ。
コーヒーを飲み終わる間にわずかに逡巡した後、次のアイデアのスケッチに入る。
問題 1
あなたはある企業のAWSアーキテクトです。既存のオンプレミスの金融データをAWSに移行する必要があります。移行後、すべてのデータは 削除や上書きができないように保護 する必要があります。
A. AWS Storage Gateway + Amazon EBS + Object Lock
B. AWS DataSync + Amazon S3 + Object Lock
C. AWS DataSync + Amazon EFS + Object Lock
D. AWS Storage Gateway + Amazon S3 + Object Lock
回答C。 AWS Storage Gateway は名称てきにオンプレミスと sync しなさそうだから、DataSync -> EFS だと考えた。S3はストレージだからなし。
問題 2
Auto ScalingグループにあるEC2インスタンスのスケールインが発生しました。
デフォルトのスケールインポリシーの場合、どのインスタンスが優先的に削除されますか？（3つ選択）
C. 最も最近作成されたLaunch Templateのインスタンス
D. 最も古いLaunch Templateのインスタンス
スケールイン, スケールアウトの違いがわからない。アウトは拡大する、インはスケール縮小？
回答：A, 多いほうから削る。D, 古いものは削除、E,残り時間が少ない順から削る？
問題 3
グローバルに展開するアプリケーションがあり、ログイン処理が遅く、HTTP 504エラーも発生しています。
CloudFrontを利用してコストを抑えつつ、パフォーマンスを改善する方法として適切な組み合わせはどれですか？（2つ選択）
A. 複数リージョンにアプリを展開してRoute 53のレイテンシルーティングを利用
B. CloudFrontのオリジンにCache-Control max-ageを設定してキャッシュ比率を上げる
C. Lambda@Edgeを使って認証処理をユーザーに近い場所で実行
D. 各リージョンに複数VPCを作りTransit VPCで接続してSAMでLambdaを配置
E. CloudFrontのオリジングループでフェイルオーバーを設定
回答：BとCかな。Aは手数が多すぎる。非効率かなと。Dも工数がかかりそう。手作業で複数作るのかな？Eはこういう設定して意味あるのかなと思った。
問題 4
医療系企業がAWSで複数のアプリケーションVPCを作成します。各アプリは 共有サービスVPC にアクセスする必要があり、アプリ同士も通信します。
将来的に数十のアプリが追加されることを考慮した場合、管理負荷を最小化する構成はどれですか？
A. VPC PeeringでアプリVPCと共有VPCを接続
回答：A 他はなんか怪しい。
問題 5
アプリケーションは EC2 + RDS SQL Server で構成されています。
要件: EC2とRDS間の通信はすべて暗号化されていなければならない
どの設定が最適ですか？（2つ選択）
A. EC2とRDSのセキュリティグループでポート443のみ許可
C. rds.force_sslパラメータをtrueにしてDB再起動
E. RDSルートCA証明書を取得しアプリでSSL接続を設定
回答 AとC。Eも正解っぽく感じる。
ーーーーー
答え
ーーーーー
問題 1
あなたの回答：C (AWS DataSync + Amazon EFS + Object Lock)
実際の正解は B (AWS DataSync + Amazon S3 + Object Lock)
理由：
Object Lock は Amazon S3 のみ がサポートしています。EFSやEBSではできません。
AWS DataSync で S3 にデータを移行し、Object Lock を有効にすると、削除や上書きを防止できます。
Storage Gateway はハイブリッド用途（オンプレと同期）に便利ですが、このシナリオではすべてクラウドに移行するため不要です。
問題 2
あなたの回答：A, D, E
正解：A, D, E ✅
理由：
スケールインは 余剰リソースを減らす 操作（インスタンスを削除する）
選ばれたAZの中で 最も古いLaunch Templateのインスタンス を削除
※「スケールイン＝縮小」「スケールアウト＝拡大」で覚えておきましょう。
問題 3
あなたの回答：BとC
正解は C と E
理由：
Lambda@Edge → 認証処理をユーザーに近い場所で実行でき、ログイン処理を高速化
B（Cache-Control max-age）は静的コンテンツのキャッシュ用で、このシナリオの問題（認証処理の遅延や504）には直接関係なし
AやDはコストや運用負荷が高く、今回は「コストを抑えて改善」が条件
問題 4
あなたの回答：A
理由：
VPC Peering は数が増えると 接続管理が爆発的に複雑 になる
Transit Gateway を使えば 1つの中央ハブ で全VPCを接続でき、管理負荷が大幅に削減
VPNやDirect Connectはオンプレ接続用なので不適切
問題 5
あなたの回答：AとC
正解は C と E
理由：
rds.force_ssl=true → RDSがSSL接続を強制
クライアント側で RDSルートCA証明書を使用 してSSL接続
TDEは 静止データの暗号化 用で、通信の暗号化には関係なし
AMD A8（例えば2014年頃のA8-7600など）から最新のCPU（Ryzen 9000シリーズやCore i14/15世代）に換装した場合、AV1エンコードのスピードは「測定不能」あるいは「数十倍〜百倍以上」という次元の差になります。
これには、単なる計算速度の向上だけでなく、「ハードウェア支援」の有無が決定的に関わっているからです。
1. ソフトウェアエンコード（CPUパワーのみ）の場合
AMD A8はAV1という新しい規格が登場する前の設計であるため、最新の効率的な命令セット（AVX-512など）を持っていません。
AMD A8: 1fps（1秒間に1フレーム）すら出ない、あるいは処理が重すぎて途中でエラーになるレベルです。
最新CPU (Ryzen 9 / Core i9): ソフトウェアエンコード（libaom-av1等）でも、設定次第で実用的な速度（フルHDで数十fpsなど）が出せます。
倍率の目安: 純粋な計算能力の差だけで10〜20倍以上の差がつきます。
2. ハードウェアエンコード（内蔵GPU）の場合
ここが最大のポイントです。最新のCPUには、AV1を高速に処理するための専用回路「AV1エンコーダー」が搭載されています。
AMD A8: AV1のハードウェアエンコード機能は非搭載です。
最新CPU: Ryzen 7000/9000シリーズや、Intel Core 第12世代以降（内蔵GPU）には、専用のハードウェア回路が組み込まれています。
倍率の目安: ソフトウェア処理に頼るA8に対し、最新CPUのハードウェアエンコードは「瞬きする間に終わる」レベルの差になります。比較自体が酷なほどで、体感では100倍以上のスピード感になります。
