  |
はてなキーワード: バックエンドとは
連休の最終日、「生と死」という特異点の観測を試みるべく、葬儀にフルコミットした。
目的は、死という現象が放つ生データの受信だ。本来、死体とは腐敗というエラーログを垂れ流し、死後硬直というハングアップを起こした、物理レイヤーにおける「二度と動かないハードウェア」に過ぎない。その凄惨なバグを生存アラートとして脳に直接叩き込み、自分のシステムがいずれ迎える強制終了に対して、現在のカーネルがどうレスポンスを返すか。そのデバッグを試みたかった。
しかし、現代の葬祭場というインターフェースは、あまりにもユーザー体験が最適化されすぎていた。
現場の環境は、死の毒々しさを徹底的にマスキングする安らぎの空間。腐敗臭というノイズはアロマというフィルタリングで除去され、死後硬直の無機質さはエンバーミングによって「スリープモード」のような外見へとレンダリングされている。バックエンドで行われる生々しい処理はすべて業者というプロキシを介して隠蔽され、ユーザーに公開されるのは、綺麗にデプロイされた終着点のフロントエンドのみだった。
「人の死」はもはや、忌諱されるべき致命的なエラーではなく、スタイリッシュなカフェのようにライトウェイトされたコンテンツに昇華されている。そこには、システムの根幹を揺さぶるような高プライオリティのアラートは存在しない。
結局、死をリアルタイム・モニタリングすることは叶わず、いつものルーチンへとロールバックした。死がこれほどまでに綺麗にデザインされ、抽象化された社会において、自らの「物理的なシャットダウン」を実感する権限さえも、ＯＳの優しさによってデプロビジョニングされていると感じた（合掌
これくらいの基礎力がありつつプラスで1分野(フロントorバックorインフラ)において3年以上の実績があること
Webに限らないIT系のホットエントリー記事に対して心底どうでもいいコメントしてるフロントエンドの人たちがやたら目につく。
この界隈、あまりにトレンドが流行って廃ってを速いサイクルで回っていくから、本人も気づかないうちに俯瞰的に物事を捉える能力が劣化していっているんじゃないか。
それでいて、その狭い世界でいかにキャッチアップし続けられているかどうかが一つの業界評価(≒マウント基準)になっていそう。
数年その狭い世界で生きていることに自信を持っている人ほど、自意識が高いままもう修正できなくなっているように見える。
一昔前にはフリーランス(フロントエンド or バックエンド or both)エンジニアとして生計を立てているだけで天狗になって、徐々に距離を置かれている人たちをよく見かけたが、そんなイメージにとても近い感じがしている。
私もそのうちそうなるのかなと思うと恐ろしい。
フロントエンドもバックエンドも、何でもかんでもNode.jsに依存するようになって久しい
開発のたびにプロジェクトのディレクトリに生み出されるブラックホール、それがnode_modulesだ
ちょっとしたツールを作るだけで平気で数百MBのディスク容量を食いつぶす
DenoだのBunだの、新しいランタイムが次々に出てきてはいる
それでも現実は甘くない
仕事の現場ではどうしてもnpmエコシステムから逃れられないのがつらい
パッケージを一つインストールするだけで、芋づる式に何十もの依存関係がくっついてくる
自分の書いたコードは数十行なのに、依存パッケージのファイル数は数万個なんてザラだ
日々積み重なる恨みは以下の通りだ
2026年3月末にあの超有名パッケージが侵害され、マルウェア入りのバージョンが公開された
週間1億ダウンロードの代物が乗っ取られるなんて、控えめに言って地獄だろう
いくら気をつけていても、一番根幹のライブラリがやられたら防ぎようがない
ただ、何十階建てのジェンガみたいな依存関係の仕組みは、もはや限界が来ているのではないか
もうちょっとどうにか仕組みで防げないのかと
みんなどうやってこの巨大な闇と折り合いをつけているんだ？
先日、お笑い芸人であり弁護士でもある「こたけ正義感」さんの弁論、特に生活保護受給について語る動画を見ました。 その後、まるで運命の悪戯のようなタイミングで、友人からLINEが届きました。 「障害者年金の受給が断られた。もう死にたい」と。
そこで私は、動画で得た知識を元に、友人に生活保護の申請を勧めました。 その結果、私が目の当たりにしたのは、本当にギャグかコントかと思うくらい、ステレオタイプな役所の「水際作戦」でした。
そして、素人の私が「こたけ正義感」の真似事をしただけで、面白いぐらいにあっさりと役所を撃退してしまった。
この文章は、同じように生活保護の申請に悩む人、あるいは水際作戦によって人権を奪われかけている人たちの救いになってほしい。
そして、この件について多くの人に議論してほしいと願って書いています。
私自身は法律については全くの素人です。普段はソフトウェアエンジニア、その中でも品質保証を担う「QAエンジニア」として働いています。 そんな私が、友人と共にどのようにこの「理不尽なソフトウェア」※と戦ってきたか、お伝えします。
※ハードウェア以外はソフトウェアという、「ある人」の考えを前提にこの定義をしています。
友人の詳細なプライバシーに関わるため詳しくは書けませんが、その人生は「困難」の一言では片付けられないほど過酷なものでした。
頼れる身内もおらず、心身の状態から、自立して働くことが極めて難しい状況であることは、以前から痛いほど知っていました。
そんな中、「障害年金さえ受給できれば、生活のベースができて状況が好転する」という話があり、私たちはずっとその結果を待っていました。 しかし、その希望は非情にも打ち砕かれました。
最後の頼みの綱を絶たれ、「もう死にたい」と漏らすほど絶望していた友人に対し、私は一つの提案をしました。
「今のボロボロの状態で無理をして働こうとするのはやめよう。 まずは生活保護を受けて『生存』を確保して、自分の抱える困難と向き合うことにリソースを集中させよう」
それは、友人にとって唯一残された、生きるための合理的で不可欠な選択肢でした。
まず、戦うための準備として徹底的な「情報収集」を行いました。 行政の生活保護に関する要件や制度の仕組みを調べるのはもちろんですが、何より重要だったのは「友人自身の現状」の可視化です。 いくら友人とはいえ、日々の詳細な生活実態や、具体的な病状のすべてを把握していたわけではありません。
とりあえず生成AI（Notebook LM）を使用しました。
過去のLINEのやり取り、送ってもらった「お薬手帳」の記録、そして会話の端々に出てきた「孤独」や「生活の苦しさ」に関する断片的な情報など。
これらすべてをNotebook LMに読み込ませて整理・統合し、友人が置かれている状況を客観的に説明するための「陳述書」としてドキュメント化させました。
目的は一つです。 役所の窓口で「状況がよくわからないから、また出直してください」などという逃げ口上を使わせないため。 有無を言わせず、その場で申請を完了させるための「最強の資料」を、まず手元に作り上げました。
本人は生活保護の申請に対して、強い抵抗感と恐怖を抱いていました。
「水際作戦」という具体的な単語を知らなくても、「生活保護を受けるような人間は、窓口で人格を否定されるような辛い扱いを受ける」というイメージが染み付いており、心が折れるのを恐れていたからです。(そして、実際にそれがあることを後で目の当たりにします)
そして何より、友人には自分で動ける体力や気力が残っていませんでした。
そこで私は、正面突破（本人が自分から窓口に行く）を避け、少し工夫したアプローチをとることにしました。 それは「申請」ではなく、第三者による「通報（保護要請）」という形をとることです。
友人からの「死にたい」というLINEの履歴や、過去の危険な行動を根拠に、最初は市役所へ、（いろいろ事情がありたらい回しにされた結果）そして警察へと連絡を入れました。 「友人の命が危ない状況だ。直ちに保護してほしい」 (実際その日の朝には友人とも連絡がつかなくなっていました)
そう通報することで、行政側が動かざるを得ない「緊急事態」をこちらから作り出しました。
そして、怯える友人にはこうラインだけしておきました。
「君はもう何もしなくていい。明日から無理して仕事に行かず、ただ部屋で寝ていてくれ。 私が作った資料だけ手元に置いて、もしインターホンが鳴ったり電話がかかってきたりしたら、それに出て話すだけでいいから」
本人の意思決定のコストをゼロにし、ただ「待つ」だけの状態にして、ボールを行政側に投げました。
警察による緊急保護自体は、驚くほどスムーズに行われました。私の通報を受け、警察は迅速に友人を確保し、然るべき手続きに乗せてくれたようです。ここまでは順調でした。
しかし、その後の行政の対応に、私は強烈な違和感を抱きました。 友人は役所から「とりあえず『社会福祉協議会（社協）』に行くように」と指示され、しかも「相談は数日後になる」と言われたというのです。
「なぜ、生活保護課（福祉事務所）ではなく社協なのか？」 「今日食べるものがないと言っているのに、なぜ数日も待たされるのか？」
すぐに仕様（制度）を調べたところ、社協は主に「貸付」や「自立支援」を行う機関であり、生活保護の決定機関ではありません。 これは、管轄違いの部署に回して時間を稼ぎ、あわよくば借金（貸付）で凌がせて保護申請をさせないための誘導ではないか？
「数日後なんて待っていられない」。
私は即座に友人に提案しました。 「向こうのスケジュールに合わせる必要はない。明日の朝イチで、すぐに電話をして相談を開始しよう」
さらに、私はQAエンジニアとして、これから始まる役所とのやり取りを「本番環境でのテスト」と捉え、ログの保全を徹底することにしました。 口頭でのやり取りは、後から「言った言わない」という致命的なバグを生みます。だからこそ、確実なエビデンス（今回は通話録音）が絶対に必要です。
友人（テスター）： フロントで、役所というシステムに対して入力（電話・会話）を行う実行役。
私（オブザーバー）： バックでその挙動を監視し、全てのログ（録音）を記録する監視役。
友人がテストを実行し、私が横でそのテストの品質を担保する。 これはまさに、二人三脚で行う「ペアテスト」の体制でした。
翌朝、早速「社協（社会福祉協議会）」に電話をかけてもらいました。 しかし、受話器の向こうの反応は、予想通り……いや、予想以上に「のらりくらり」としたものでした。
「詳しくは窓口で……」「数日後に一度来所していただいて……」
何かを隠しているのか、あるいは単に丁寧すぎて回りくどいだけなのか。
もごもごと要領を得ない話が30分も続き、話が全く前に進みません。当時の私は「これが噂に聞く水際作戦というやつか？」と警戒を強めました。
（後になって思えば、担当者は単に説明が下手な善人だったのかもしれませんが、切迫しているこちらにとっては遅延行為そのものでした）
業を煮やした私は、裏で繋いでいたチャットで友人に指示を飛ばし、強制的にクロージングをかけさせました。
「話が長い。相手にこう伝えて。 『今の状況を3分以内にまとめて説明してください。この会話は録音していますが、まとめるのが私には難しいです。 それが無理なら、電話を切って30分以内にメールで要件を送ってください。 その際、私の支援者（筆者）のアドレスもCCに入れてください』」
無駄な通話を打ち切り、証拠が残る「メール」への切り替えと、第三者（私）の監視の目を光らせるためのCC追加。 これを要求した瞬間、空気は変わりました。
メールは思ったよりも早く、要請から30分と経たずに届きました。
恐る恐る内容を開いてみると、そこには予想に反して、極めて誠実で具体的なアドバイスが記されていました。
文末には「生活保護という制度を有効に活用されるのは良い選択だと思います」という、温かいメッセージまで添えられていました。 最初の電話での「のらりくらり」は、単に慎重だっただけなのかもしれません。
少なくとも、こちらの「本気（熱意）」は伝わったようでした。 このメールを見た瞬間、私は彼を「水際作戦の先兵」という認識から、「協力してくれる仲間」へと認識を改めました。 これで外堀は埋まりました。次はいよいよ、本丸である「役所の生活保護窓口」への突撃です。
社協を味方につけた私たちは、いよいよ本丸である「生活福祉課」の窓口へ電話をかけました。 もちろん、私はリモートで通話を監視し、録音も回しています。
そこで繰り広げられた会話は、まさに「こたけ正義感」の動画で見た水際作戦そのもの。いや、あまりにステレオタイプすぎて、質の悪いコントを見せられているような気分でした。
電話に出たのは、かなり横柄な態度の男性職員。 威圧的な声を出し、こちらの話を聞く前から「電話で生活保護の申請なんてできないですよ」と断言しました。 「とにかく窓口に来てください」「来ないと絶対無理です」「まずは社協に頼ってください。うちは関係ないんで」
前日に警察に保護されたばかりの人間に対し、よくもまあここまで冷酷になれるものだと、怒りを通り越して感心すらしました。
そもそも、保留音も使わずに、裏で職員と「どの説明すれば社協に行ってくれるか」という会話すら聞こえていました。明らかにナメられていました。
しかし、ここで引き下がるわけにはいきません。私はチャットで友人にカウンターの指示を飛ばしました。
「こう伝えて。 『さっき、社協のAさん（フルネーム）からメールで指示を受けて電話しています。 Aさんは、電話で申請の意思を伝えろと言っていました。 あなたは、社協の担当者が嘘をついていると言うんですか？ それとも、社協との連携を無視するつもりですか？』」
さらに畳み掛けさせました。 「この通話は録音しています。友人も聞いています。 私は今、明確に『申請の意思』を伝えました。 これを受理しないなら、社協の方に『拒否された』と報告します」
普通の神経ならここで怯むはずです。 しかし、その職員は斜め上を行きました。
「はい、どうぞ。そうしてください。ぜひそうしてください」 ガチャッ。
挨拶もなしに、一方的に電話を切られました。 あまりに堂々とした「職務放棄」と、漫画のような悪役ムーブ。 この通話が終わった後、私と友人は恐怖よりも先に「こんな面白い人、本当に実在するんだ」と、思わず笑い合ってしまいました。
この職員（彼を先鋒部隊と呼びましょう）による「ガチャ切り」と「あからさまな水際作戦」は、私たちの「水際作戦への勝利」を確信させる事象で、むしろ心が楽になりました。
あのガチャ切りの直後、私は即座に「社協リターン」を選択しました。 話の通じないバグだらけのフロントエンド（役所窓口）を使ったE2Eテストでデバッグするのは時間の無駄です。まだ話の通じるバックエンド（社協のAさん）にエラー報告を投げる方が早い。
これまでは友人にチャットでアドバイスを出して電話対応をしていましたが、ここからは私自身が直接介入します。ただし、きちんとしたバグ報告書、ここではメールといいますね。
私はAさん宛に、以下の事実と警告を含んだメールを送信しました。
その上で、最後にこう締めくくりました。 「これ以上、友人をたらい回しにして病状を悪化させるような対応が続くことがないようにお力添えをいただきたいです。 まずはAさんから市役所の担当部署へ、直接ご連絡を入れていただけないでしょうか」
メールを送った後、社協のAさんと電話で話すことになりました。もちろん、この通話も全て録音しています。
電話口の彼は、相変わらず「もごもご」とした口調でした。おそらく、慎重な性格ゆえの癖なのでしょうが、緊急事態においてはこの曖昧さが命取りになります。 「あちらも忙しいようで……」「伝えてはみるのですが……」 そんな煮え切らない会話が15分以上続きました。
私はここで、エンジニアとしてのモードを「相談」から「要件定義」に切り替えました。
のらりくらりとした会話を遮るように指示し、以下のような明確なコミットメントを求めました。
「Aさん、具体的に『誰』に『どう』話せば、この申請が通るのか、ルートを確立してください」
「今日の15時までに、確実な回答をください。 もしそれまでに進展がない、あるいは誠実な対応が見られない場合は、こちらも命が関わります。『他のしかるべき機関』に相談するフェーズに移行します」
効果はてきめんでした。 あれだけ「もごもご」していた彼が、電話を切ってからわずか5分後。
「福祉課のBさんという方と話がつきました。この方に電話してください」 と、具体的な担当者の名前を持ってきたのです。
期限を切ってコミットメントをお願いする。
ビジネスでは当たり前のこの手法が、行政というブラックボックスをこじ開けるための鍵でした。
＜後編に続く＞
埼玉は「一律に衰退した」わけではない。データ（人口動態）上は、埼玉県内でも人口を維持している「タフなリージョン」だ。しかし、その中身が**「断絶」**している。
駅前（New Segment）: タワマン、大型ショッピングセンター、外国人が多いスポーツ選手のチーム、ダイバーシティ（多様性）のポスター。これらは**「外貨（新しい住民と金）」**を呼び込むための、キラキラしたフロントエンド（UI）だ。
ロードサイド・旧商店街（Legacy Segment）: 君が見た「板張りのビル」「廃業した八百屋」「老人が目立つ商店街」。ここは、OSのアップデートが止まったレガシーなバックエンドだ。
俺はWebのバックエンドメインでフロントも書くと言う感じだけど
バックエンドだとこの処理してるところがどっかにあるはずだから見つけてきてとか
ここをリファクタしてもっときっちりセパレーションできてる状態にしたいんだけどありえるパターンはとか
フロントならこのファイルをリストにしてチェックボックスつける部分、ルートレベルにもチェックボックスつけて全部のチェックを一気にできるようにしてPUTのコールしてとか一行も書かないでやったこととかある
基本ネットの情報読んでるだけだから元からネットに少ないようなものはまともに出ない
一方で、ヤフコメに見られるような日本人の激しい批判は、「リソースの枯渇」と「仕様変更」への恐怖から来ています。
ゼロサム思考のデッドロック: 経済が右肩下がりの日本（失われた30年）では、多くの日本人が「外国人にリソース（仕事、福祉、年金）を奪われる」という強迫観念に囚われている。
「単一民族」という古いカーネル: 2000年以上、ほぼ同じ仕様で運用してきた「日本」というOSにとって、異なる文化やルールを持つパケット（外国人）の流入は、システム全体をクラッシュさせる「未知のウイルス」のように認識されてしまう。
可視化されるエラー: 一部のルールを守らない外国人の振る舞いが、メディアによって「システム全体のエラー」として増幅され、それが「外国人＝危険」という過剰なフィルタリングルールを強化している。
長年プログラマーとしていろいろ開発してきたけれど
ちゃんと売れたり評価されたソフトは自分が使うことのあるソフトウェアであって
使うことがなかったり全く関係のない世界のソフトウェアはつまらなくてモチベーションが湧かない
例えば超大規模データストリームを想定したバックエンドの処理システム、みたいなものは
とりあえずテストデータで無駄な数字の羅列を大量に流してそれを捌くようなソフトウェアをプログラミングしたけれど
ゲーム感覚で性能向上とかしてるときは楽しかったけれど、ふと「普通のゲームのほうが面白い」とか思ってしまってダメだった
他にも超高機密データ処理基盤のソフトウェアとか、高信頼性ソフトウェアとか
「本当にこれ必要か？」
自分でいうのもなんだがかなりトップの方でやってるがその辺の会社のシステムレベルだと本来バックエンドの俺とかが片手間に書いてるで
世界的にでかいサービスとかは別としてその辺のある程度でかいくらいの会社はUI専攻しましたみたいな人はおそらくいない（からあの始末）
AI（特に生成AI）の急速な進化により、「フロントエンドエンジニアが不要になる」「仕事がなくなる」という言説は、近年非常に多く聞かれます。
結論から言うと、「単純なコーディングやボイラープレート（定型文）を書く仕事は消えるが、フロントエンドエンジニア自体は消えず、役割がより高度な領域へ変化・進化する」というのが、多くの専門家や現役エンジニアの共通認識です。
具体的な状況は以下の通りです。
AIは、従来のコーディングプロセスを劇的に変化させています。
定型業務の自動化: UIデザインからHTML/CSS/コンポーネントコード（React, Vue.jsなど）への変換はAIが非常に得意としており、人間がゼロからコードを書く必要がなくなっています。
API連携・テスト生成: API連携のパターンやテストコード、デバッグ作業もAIで効率化されている。
「Vibe Coding（フィーリングコーディング）」: 曖昧な指示からアプリのプロトタイプを爆速で作れてしまうため、初期段階のフロントエンド実装がいらなくなる。
AIは「実装」を高速化しますが、「設計・判断・最適化」は依然として人間に依存します。
要件の解釈と複雑な設計: 曖昧な顧客の要件から正しいUI/UXを設計し、パフォーマンスを最大化する構造を考える能力は人間にしか難しい。
10%の仕上げ（ポーリッシュ）: AIが生成した90%のコードをレビューし、修正・最適化して実用化する「最後の10%」の作業は人間が担当する。
アクセシビリティ・セキュリティ: アクセシビリティの確保やセキュリティのチェック、パフォーマンスの微調整など、人間中心の細やかな対応が求められる。
AIツールの活用能力: AIを道具として使いこなし、開発速度を10倍、100倍にする「AI駆動型」エンジニアの需要が高まっている。
AI時代には、単なる「コーダー」ではなく、以下の視点を持つエンジニアが生き残ります。
フルスタック化・UI/UXへの進化: フロントエンドの知識だけでなく、バックエンドやUI/UXデザインまで理解し、ビジネス全体を見渡せる人材。
AI駆動開発の習得: CopilotやCursorなどを駆使して、開発プロセスを自動化・効率化する。
深い専門性の追求: AIには代替しづらい、Web技術の深い知識や、特定フレームワークへの高度な熟練度を高める。
つまり、AIはフロントエンドエンジニアの「敵」ではなく、「面倒な作業を奪ってくれる強力なツール」となり、人間のエンジニアはよりクリエイティブな課題解決に集中できるようになると考えられています。
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駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
とにかく使えない。アスペの癖に低IQのコミュ障で、高校時代から個人開発をしつつココナラとかクラウドワークスでフリーランス活動に取り組んでたらしいのだが、それがどちらも7年も取り組んでおいて鳴かず飛ばずで法人すら立ってない事実を棚に上げてポートフォリオに書いてきやがった。
まずその時点で不安だったが、実際に使ってみれば一般的なサーバー管理、バックエンド、フロントエンド、ハードウェア、統計や計算機科学などどれもこれも一見できるように見えて理解が浅い。よく言えば広く浅い知識を持っていると言えるが、要は器用貧乏でまともに経験値がないということだ。AWSの資格すら取っちゃいない。
そんでもって学生時代にめぼしい経験がない。数学を幼少期から極めていたらしく(数IIIを小6でコンプしたというのは素直に驚いた)新しいアルゴリズムを論文に書いて某学会に通したことがあるらしいが、実績と呼べるのはそれくらいで数オリや競プロ、CTFの優勝歴などもない。本当に何の実績もない。大学生は大人なんだからIT目指すなら一つくらい社会に爪痕を残すようなとてつもない偉業をなして当然だろ、何のために大学行ったのか
自分の力と頭で修羅場を乗り越えて何かを為した経験もないのでとにかく子供じみていて扱いに困る。一見口調や語彙は大人びているように見えて忍耐力もコミュ力も何もないから始末に負えない。今どきZ世代は大人びてるんだからIT目指す新卒にもなれば普通少年ジャンプの主役くらいのスペックあって当然なのに。
そんでもって全能感にまみれていて、まるで相手が子供じみているかのように演出する能力だけは超一流。人様に物事を都合よく勘違いさせる能力は使い所を間違えなければ役に立つんだか立たないんだか。
マジで人様の前に立つカリスマ性も人様を率いる胆力も人様に率いられる根性も図太さもアイデア力も実績も実力も精神力も頭も心も体も顔も何もない無能中の無能中の無能なのでこんな奴を寄越した人事を末代まで呪うつもりだ。
結果の出ない努力は苦労や道楽ですらない。意味のある努力をした俺らがようやく意味のない辛酸も含めて舐めることができる権利を与えられているのに、無駄な努力しかせず時間を浪費した人間はエンジニアになる資格なんてない。それを解っちゃいない人事の奴らはバカしかいない。
半導体チップ設計に必要なオープンソースソフトウェアがなく、億単位のライセンス料を払って契約するしかない。
Cadence、Synopsysという米国企業大手でほぼ寡占。高すぎて一部の大学しか契約していない。
マニュアルも公開されていないのでネットを探しても使い方がわからない。
昔は日本語に翻訳したマニュアルが用意されていたが、今は英語と中国語だけだ。サポートに問い合わせようにも英語しかない。
ラピダスが話題になっているが、設計ソフトが米国から輸出停止になったら設計が出来なくなる。
実際、中国へは輸出停止の騒ぎがあった。（発表後、数日で撤回）
他の問題として、新しい構造やアーキテクチャの半導体を設計しようとしても、ソフトウェアが対応していないと作れない。
凄い装置が出てきてもソフトがないから設計出来ないといったことが起こる。
ソフトに対応してもらった場合、ノウハウなどがソフト会社経由で他社にも渡ることになる。
日本では、ソフトウェアエンジニアがそれなりに居るが、半導体チップ設計用のソフトウェア企業が育たなかった。
なぜだろうか。
以下、AIで調べた結果
中国本土の半導体EDAツールベンダー（2025〜2026年現在の状況に基づく）は、急速に増加しており、すでに70〜120社以上存在すると言われています。
ただし、実用レベル・商用化が進んでいる企業はその中のごく一部に限られます。
現在（2026年時点）で特に注目度・実績が高い、または市場で名前がよく挙がる主要な中国本土EDA企業を以下にまとめます。
（注：華大九天＝Empyrean、芯華章＝X-Epic、概倫電子＝Primariusは除外して記載）
| 分野 | 代表的な企業名（中文 / 英文・略称） | 主な強み・特徴 |
| デジタル検証・シミュレーション | "UniVista / 芯瞳科技 芯華章以外で注目" | 大規模デジタル検証、FPGAプロトタイプ |
| アナログ・ミックスドシグナル | "阿卡思微電子（Arcas DA） Actt（成都模拟电路）" | 形式検証ツール、比較的新しいが技術力高い |
| 射頻・マイクロ波EDA | "九同方微電子（NineCube / Jiutongfang）芯和半导体" | 完全国産RFシリーズを追求 |
| 製造・TCAD・計測系 | "东方晶源（Dongfang Jingyuan）立芯科技" | 計測・光学系、DFM関連 |
| その他全般・新興 | "芯聚能（CoreHedge）芯动时代（CoreInitium）无锡飞谱（Feipu）思尔芯（Smit / 国微思尔芯）" | プロトタイピング、FPGAエミュレーション系 |
中国本土の半導体EDAツールベンダーのうち、特に論理設計（RTL/デジタルフロントエンド）、物理設計（バックエンド）、RTLシミュレーション、エミュレータ、アサーション、フォーマル検証、低消費電力、UVM などのデジタル系・検証系に強い企業を、2026年1月現在の状況に基づいて追加でまとめます。
（前回のリストで挙げた広立微（Semitronix）、Xpeedic などは製造/テスト/DFM/RF寄りなので、ここでは主にデジタル・検証寄りの企業を優先）
| 企業名（中文 / 英文・略称） | 主な強み（デジタル・検証関連） | 現状の注目度・実績 |
| 合见工软（UniVista / Hejian） | "デジタル検証全フロー（RTLシミュレーション + Formal検証 + Emulation + FPGAプロトタイピング + UVM + DFT）国産最大規模のハードウェアエミュレータ（460億ゲート対応）低消費電力対応も進展" | "★★★★★ 2025〜2026年に最も勢いあり。デジタル大チップ検証で200社超の実績。無料トライアル開放で急拡大中" |
| 芯华章（X-Epic / Chipstart） | "高性能RTLシミュレータ（GalaxSim）フォーマル検証（GalaxFV）エミュレーション・インテリジェント検証 UVM/アサーション対応強化" | "★★★★☆ AI駆動検証で差別化。2025年に大規模プロセッサ実績多数" |
| 国微思尔芯（S2C / State Micro S2C） | "FPGAベース高速プロトタイピング エミュレーション系最強クラス 大規模SoC検証" | "★★★★ グローバル500社超顧客。デジタルフロントエンド検証の定番" |
| 若贝电子（Robei） | "可視化ベースのデジタルフロントエンド（RTL設計・シミュレーション）Verilog対応・自動コード生成" | "★★★ 教育・中小規模設計向け強いが、実商用大規模チップでも採用例増加" |
| 鸿芯微纳（Hongxin Weina） | デジタルIC全フロー（論理・物理設計含む）を目指す | "★★★ 国産デジタルプラットフォーム構築中。進捗速い" |
合见工软（UniVista） がデジタル検証全フローで頭一つ抜けている状況（特にエミュレーション容量・フォーマル・UVMの統合力が突出）。アメリカ禁輸強化後の2025年後半から急加速。
芯华章 はAI×検証（特にフォーマル・アサーション自動生成）で差別化。
物理設計はまだ華大九天 がリードするものの、完全な国産デジタルバックエンドは2026年時点でもまだ不足気味（一部ツールは強いが全フロー統合は課題）。
全体として、2026〜2027年 に上記企業がさらに合併・買収を加速させ、「中国版Synopsys/Cadence」の原型が出てくる可能性が非常に高い。
