私が「AIには開発できない（だから引き続き人間が担うしかない）」と一年ほど前まで言い続けていたものがいくつかある。その代表がOSだ。自分がかつてOS開発に関わったから、という思い入れもある。だがそれを抜きにしても、OSがもっとも難易度の高いソフトウェアの一つだと言って、正面から反論する人は少ないだろう。優秀なエンジニアでなければ担当できない領域だ。AIがいくら優秀になっても、さらに進化を続けても、この複雑なソフトウェアだけはAIには作れない。そう考えていた。 OSと同じくらい難しいと思っていたものに、コンパイラがある。これもコンピューターサイエンスを修めた人間にしか書けず、AIには当面無理だろうと考えていた。 ところが、コンパイラは、もうAIが書けるようになっていた1。気づいたら、そうなっていた。そして今回のGoogle I/O 2026で、とうとうOSまでAIが書いてしまった。 まず、G
いや分かる、分かるぜ？毒親なんかとは早く離れた方が良いってことは誰よりも分かっている 何故なら俺は結婚を反対されて自分の親兄弟姉妹親戚すべてと絶縁しているからだ 20年生まれ故郷に帰っておらず、その間にこの件に何も関係がない可愛がっていた姪甥は成人し、祖父母は亡くなったが葬式に出られていない。祖父母からすると孫の1人が急に失踪した形になっていただろう 俺が生涯のパートナーと決めた相手へ対し、直接「認めない」と言う姉妹、「水商売女か」とまで言う両親、フォローのつもりなんだろうが「代わりの女なら紹介してやる」と言う兄弟 俺の可愛い女が泣いている、黙って俯いてその暴言にポロポロ涙を流し、俺はどうしても許せなかった、俺はその場で絶縁を宣言し故郷を離れた 即日仕事を辞めた。上司に事情を話すと引き留められたが最後は「会社は俺がどうにかしてやる頑張れよ。お前男だよ。応援してる」とまで言ってくれた 2日目
インド民はとにかく何かにつけて「言い訳」を唱えてくる。まず、インドに着任してイライラするのはこのインド民のコミュニケーションモードである。これはインド民の自己防衛本能の一種であるが、実際に部下や取引相手として対峙した場合にはなかなか手ごわい。その結果、彼らとの議論が面倒臭くなり、適当にやり過ごし、こちらが相手の主張を飲み込んでしまった場合、インド民は、「やはり俺が正しかった」と本気で思いこむ。よって、議論や責任を有耶無耶にすることは、長期的に見れば相互に誤解を生むことになり、結果として逆恨みや約束の不履行などに繋がる。相手が部下であれば、あなたは彼や彼女をコントロールできなくなるだろう。何しろ、あなたが追求をやめれば、相手は自分が受け入れられたと考えるからである。日本人であれば、無理筋な自らの主張を理解して、心のどこかで良心の呵責が発生することを期待できるかもしれないが、インド民はそのよう
設計書・コード・テストを全部AIに書かせて半年間開発してみたよ 1. はじめに 本記事は、私のチームが半年間AIネイティブ開発を行った経験とその感想をまとめたものです。 AIネイティブ開発とは、AI技術を活用してソフトウェア開発を行うことを指します。2025/10～2026/3の期間中、私たちはお客様に納品するシステムをAIネイティブで開発しました。その経験と私なりに感じたことをまとめてみました。 ※ なお、私の取組は全社的な取組とは関係ありません。 ※ あくまで、私のチームが独自に行っている取組ですので、その点はご留意ください。 2. 自己紹介 初めてテックブログに記事を書くので、簡単な自己紹介を。 名前：茂呂範（もろすすむ） 所属：株式会社NTTデータ 第三公共事業本部 デジタルソサエティ事業部 プロジェクト推進担当（参照） 立場：様々なシステムの基盤構築、基盤維持運用を担当している組
1830年頃、わずかな夜の明かりを得るためには、約3時間の労働が必要でした。しかし1992年ごろにはそれが1秒にも満たない労働ですむようになったと言われています。ロウソクから白熱電球、蛍光灯へという技術的発展が、光を劇的に安くしたのです。 そうして光が安くなったとき、人は同じ量の光を単に安く買って終わり――ということにはなりませんでした。 人々は、かつて置こうとも思わなかった場所にまで光を置き、街路、工場、看板といった、社会のあらゆる場所に安くなった光を敷き詰めていきました。そうして、工場は曇りや雨の日にも稼働することができるようになったり、深夜営業や夜の読書といった新しい活動が可能になったのです。 そこで儲けたのは、光を提供した会社だけではなく、それをうまく使った会社でした。 では、ソフトウェアや知能が安くなったとき、私たちはそれをどのように使うのでしょうか。 生成AIによる大きな変化は
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? お前がコードを書き始める前に 言っておきたい事がある かなりきびしい話もするが 俺の本音を聞いておけ はじめに これから少しの間、不器用で、偉そうで、厳しいことを言う。けれど最後まで聞いてくれれば、その裏側にあるものもわかってもらえると思う。だから先に謝っておく。生意気な口を、許してほしい。 まず、お前に話す前に、業界を取り巻く空気の話をさせてくれ。ソフトウェア業界には、昔から消えない風潮がある。 「売れたプロダクトはすべて正しい」 「品質? 障害が起きなければそれでいい」 「細かいことはベンダーに丸投げで構わない」 ビジネスの現場で生
前回記事から1ヶ月くらい経ったのでその間に得られた知見からの所見を述べる。 やっぱり実装に関するドキュメントはいらん。仕様は全てコードにある。コードをSSoT(Single Source of Truth)とすべきだ。ドキュメントとコードの二重管理はコストが大きすぎる。特にドキュメント側の管理コストが大きく、どれだけagentにドキュメントを修正しろと指示を出してもドキュメント修正の実行が確率的であるし、ドキュメントを更新するトークン数が無駄。コード読めばわかることを自然言語にわざわざ起こさんでいい。仕様がわからんくなったらclaudeに聞けばいいのでドキュメントを永続化する必要性が皆無すぎる。ドキュメント書かせるくらいならclaudeさんに感謝のメッセージを送った方がいい。限りある電力を無駄にするな。結論として仕様駆動開発はウソです。少なくともおれにとってはウソでした。手間の割に効用を実
本書について 協力的多様性のための技術 『Plurality』は、社会的差異を超えた協力の力を認識し活用する、新たな技術パラダイムを描いています。テクノロジーが社会の絆を引き裂くのではなく、デジタルツールがいかに民主主義を強化し、分断を橋渡しし、人間の協力の可能性を解き放つかを示しています。 政治経済学者・技術者のE・グレン・ワイルと、台湾初のデジタル担当大臣オードリー・タンの共著である本書は、テクノ・リバタリアニズムと中央集権的AI統治の両極端の間に道を拓きます。デジタル民主主義の世界的リーダーとしての台湾の経験に基づき、技術がいかに公共の利益に資するよう設計できるかを示しています。 本書自体がその原則を体現しています：GitHubでオープンに執筆され、世界中のボランティアコミュニティにより十数カ国語に翻訳され、CC0の下でパブリックドメインに捧げられています。 本を入手する 読む・ダウ
最近AIをやりすぎている。自分でもわかるくらい頭がおかしくなっている。 まともな状態ではないから、本来は人に見える場所に文章を書いたりするべきではない。ただ、自分の状態を精神状態を記録するために書いておきたい。 初めに書いておくが、この文章では一切AIを使っていない。というのもAI使うと、さらにおかしくなりそうだからだ。調査にも構成にも使っていない。100%生身、ピュアで粗雑な状態で僕が言葉を選んで書いている。 これまでもテクノロジー全般は好きで、これまでもChatGPTなどを使って仕事の調査をしたり引っ越しをしたり英語学習に活用したりしてきた。今年のAIは、昨年までとは一味違う人間の気を狂わせる何かがあると感じている。 仕事でのソフトウェア開発の話を最初にする。多少技術的になってしまうけど、これが入り口で僕はおかしくなったし、最も急激に変化している部分なので話さないといけない。 AIコー
2026-02-18 React 19、コンポーネント設計どう変わった？〜うひょさんに聞く最新 実務Tips〜
いやもうね、ハサウェイの話ですよ。私はここ一ヶ月ほどガンダムのことばっかり考えすぎて情緒がめちゃくちゃになり私生活にも支障が出たため動画の出演や原稿書きが終わったらいったんガンダム・デトックス＝ガントックスをしなければと思っていた。お前は何を言ってるんだと思われる方もいるかも知らんがこちとらアムロに関する何らかの事象が発生すると身体症状が現れるタイプのガノタなので死活問題なんです。こんなん私が勝手にダメージ受けてるだけなので誰を責めることもできん。そういう奴もいるんですよ世の中には。みんなもたまにやるといいよガントックス。 しかし今の私はガントックスをやらなきゃいけないのにこの記事を書いている。なぜだ。最後にこれだけ言わせてくれ。「閃光のハサウェイは現代社会を予見していた」「マンハンターはICEの現状を思うと今こそリアル」ハァ～～～？？？？って言いたかったからです。 ウェブのレビューでも私
ちょうど最近このような投稿を連続して見かけたので、「コード」が何を指しているのかの自分の理解を整理しておきます。 世の中的に見ればソフトウェアエンジニアは未だに売り手市場であると言えると思うので、上記の指摘について「そんなことはないはず」と反論する人も多いと思います。 また、上のRyanさんのツイートでも That's not to say SWEs don't have work to do と書かれています。これも「ソフトウェアエンジニアはコードを書く仕事なのだから、AIが書くようになるなら仕事がなくなるだろう」と解釈されがちなところを、そうではないと念を押しているのだと思います。 では、「AIがコードを書く」とはどういうことで、その場合にソフトウェアエンジニアの仕事はどうなるのでしょうか？ ここで、我々がコードと呼んでいるものを区別することが理解に役立つと思います。 「コード」は大き
たびたび見かける「そのうちAIが直接バイナリを吐くようになるんでは」という話、原理的に難しいし、できるとしてもだれもやらないし、できるようになったとしてもだれも使わないので、今の仕組みのAIが直接バイナリを吐く未来は来ないと思います。 ここらへんも参照 AIがコードを書くようになるなら、AIだけに理解できる言語を作ればいい、のかな？ - きしだのHatena AI専用のプログラミング言語は現れない - きしだのHatena AIが読み書きするコードも読みやすいほうがいい(トランスフォーマの特性の考慮やリーダブルコードについて追記) - きしだのHatena プログラミング言語は人間が扱いやすく機械が実現できるよう論理を表現するものでありプログラムの本体 - きしだのHatena ※ LLMが生成したコードを内部でコンパイラを呼び出してバイナリにするというのは、例えばここにあるようなプログラ
本番環境で障害が発生したとき、手がかりになるのは結局ログだけだった——という経験は、多くのエンジニアが持っているのではないでしょうか。ところが、開発中に書き散らしたconsole.logは肝心なときに役に立たないことが多いものです。「ここ通った」「動いた」といったメッセージや、巨大なオブジェクトがそのまま出力されているだけでは、原因特定は困難です。 かといって、本格的なロギングライブラリを導入するのは大げさに感じることもあります。winstonやPinoは高機能ですが、設定項目が多く、エッジ環境では動かなかったり、依存関係が増えたりと、ちょっとしたAPIサーバーには重たい選択肢かもしれません。 本記事では、console.logの限界を整理した上で、実用的なロギング環境の構築方法を紹介します。サンプルコードにはLogTapeを使います。依存ゼロで軽量、Node.js・Deno・Bun・エッ
私の祖父は非常にプライドが高い人であった。 プライドが高い人間は詐欺と非常に相性が悪い。 詐欺にひっかかっても、自分が詐欺にひっかかる馬鹿だと認めてしまうことになるので、誰にも相談しない。もちろん警察にも行かない。 祖父は着払いでカニを送りつけられても、「丁度カニを食べたかったんだ」みたいな強がりを言う人間であった。 一度詐欺に合ってしまうと詐欺師のカモリストに載ってしまうのだろう。 祖父がまた違う詐欺に引っかかっただの、それを隠そうとするから発覚まで時間がかかって大変だの、母が頭を抱えながらなんか言っていたのだが、聞きたくないのであまり聞いてなかった。 その中でも、私がへーそんな詐欺があるんだ、と感心した詐欺を一つ紹介させて欲しい。 その名も「伝記詐欺」である。 まず、祖父の家に編集者を名乗る男が訪ねてやってくる。 そして「あなたは後世に語り継ぐべき素晴らしい人間なので、あなたのありがた
ぷー @bz5_bu 少しですが御香典包ませていただきました🙏 故人は全く存じ上げないけれど、きっとこのポストがなかったらやる機会無かった。 x.com/the_m_r_p/stat… 2025-10-18 23:09:14
なかやま @nkym7856 なかやまの友人です。 以前よりこのアカウントを預かっておりましたので、代理でご報告いたします。 10月12日の夜、なかやまは静かに息を引き取りました。 このアカウントは、当面の間そのままにしておく予定です。 生前、応援していただいた皆様に心より御礼申し上げます。 ありがとうございました。 2025-10-13 18:00:02
AI楽観派にとって、「動く」ことがすべての証明。 AI慎重派にとって、「なぜそう動くか」がすべての理由。 両者が同じコードを見ても、 前者は「成果物」を見ており、後者は「思考の痕跡」を見ている。 視点の深度が違うのだ。 5. 設計＝抽象、コード＝具象 コードを書くとき、頭の中には「構造」がある。 それは最初から完璧ではなく、書いて、動かして、違和感を覚えて、直していく。 命名、依存、責務、階層を少しずつ整える。 この「書きながら考える」行為こそが設計であり、 設計書よりもコードの構造そのものが本当の設計書になる。 AI楽観派の前提は、「設計と実装は分離できる」。 AI慎重派の前提は、「設計と実装は不可分」。 この一点が、AI時代の開発を分ける境界線だ。 6. バイブコーディングの議論が噛み合わない理由 バイブコーディングをめぐる議論は、 実は技術論ではなく認識論の衝突だ。 AI楽観派：AI
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
