Kenn Ejima @kenn 最近アメリカでは 無言電話をかけて何か喋らせて切断し その録音から再現した同じ声のAIで 家族にオレオレ詐欺をしかけるという ヤバい手口がじわじわ広がってて FTCが警告してる 最近の音声モデル 数秒で自分の声をクローンできるもんな 絶対日本にも来るから要注意 consumer.ftc.gov/consumer-alert… 2026-01-15 23:31:12 リンク Consumer Advice Scammers use AI to enhance their family emergency schemes You get a call. There's a panicked voice on the line. It's your grandson. He says he's in deep trouble — he wrecked the c

わりと複数の企業のお悩みが、「そもそも生成AIでやるべきでない問い」にチャレンジして疲弊してる。ので説明メモ。 大企業が生成AIを導入してうまくいかないケースの多くは、ツールの性能不足というより、業務設計がズレている印象があります。 もう少し正確に言うと、「AIが苦手な問い」をそのまま投げている。で、当然苦戦しています。 ポイントは大きく2つあります。 完璧性を要求する仕事を、やってはいけない ステップが長く連鎖する仕事も、やらせないほうがいい 順番に解説すると… そもそも完璧性を要求する仕事を、やってはいけない生成AIは確率分布で、未来を予測したり、答えを予測するマシーンです。つまり、「確率的に間違えが発生する」ことは仕様の一部です。 なので、以下のような「そもそも100%の正しさを前提とする業務は苦手」です。 正解が一意で厳密：数式の厳密計算、機械語や厳密仕様のコード生成（1文字違いで

OS とデフォルトバージョンのリストを見ると、現在主要な OS は ed25519 鍵に対応しているし、 OpenSSH 7.3 以上であれば、今回紹介する方法は実現できる。のでどれか一つでも試してみましょう。 ファイル構造 ¶複数の端末を使う場合、 dotfiles にして Git で管理することになる。 この場合管理対象が増えてくると構造化して案件やプロジェクトが終了したら ~/.ssh/conf.d/nodes/ の設定ファイルで Include をやめるか conf.old のように名前を変えれば接続先には出ず、不用意にアクセスすることを防止するが設定は保管しておくことができる。(結構、廃止したプロジェクトでも過去のアクセス情報を探すのに ssh/config を確認するケースは多い) $ tree ~/.ssh ~/.ssh ├── conf.d conf はすべてここに入れる

2026年、明けましておめでとうございます。昨年はまあまあ筆が動き11記事くらい書くことができた（それでも少ないが）今年はもっとブログに日々の思いをアウトプット出来たらいいなと思ってるのでよろしくお願いします。 さて、年明け早々声優の楠木ともりさんが結婚を発表した。まあ毎年恒例の年末年始にまとまった声優結婚発表があるやつだったのだが、とある一言がこれを「恒例行事」だと許さない賛否を巻き起こした。 それは報告文内の「学生の頃からお付き合いしている方」である。 この一文は元旦早々議論と賛否を巻き起こし長澤まさみさんの結婚というもっと重要そうなニュースを掻き消して弊TLに鎮座し続けた。 野球繋がりの友人とのLINEグループにメッセージが入った。野球選手は学生時代からの純愛を経た結婚が歓迎されるのに何故女性声優だとダメなのか分からないとの事。 この友人は既婚者なのでオタク的価値観の擦り合わせに長文

1995年5月20日午前2時半。日立製作所会長の東原敏昭さんの枕元に置いていたPHSが鳴った。「プログラムを更新できません」。JR東日本の鉄道運行を管理する東京圏輸送管理システム（ATOS）の現場担当者からだった。東原さんは当時、コンピューターシステムを手掛ける大みか事業所（茨城県日立市）でATOSの品質責任者を務めていた。交通インフラを支える止めてはならないシステムだが、JR国分寺駅で実施す

石川 宗寿（Munetoshi Ishikawa）/ 株式会社ナレッジワーク ソフトウェアエンジニア ※2025/12/18 サポーターズCoLab主催勉強会の登壇資料です。 https://supporterz-seminar.connpass.com/event/377986/ ＜セッ…

時折、「やりたいことに対してこんな複雑なことをしないといけないのはおかしい」という感覚がはたらく。ソフトウェアエンジニアの勘といってもいい。 FizzBuzz Enterprise Editionはプログラマジョークとして解されるが、実際のエンジニアリングではもっと微妙な形で表れる。たとえば設計やコードレビューの最中に「こうしたらどうなるだろうか」と思いつき、提案を実装した結果として管理すべき状態やコード量が減ったりする。(関連: 状態、結合、複雑性、コード量の順に最適化する - valid,invalid) あるいはシステム要件や仕様について話す中で表出することも多い。「新しい画面を作ってこういう情報を見せたい」であったり「ツールAと双方向に同期して検索したい」といった言葉からよくよく要求を聞いてみると、既存機能で代替ができたり、大仰なインテグレーションは不要だと気づく。 不要な仕事を減

黒い薔薇 @yjmurkmr @favoga_ さらば宇宙戦艦ヤマト　愛の戦士たち だいぶ年いってからようやく見て、これを知らんでいたのは人生損したなと言いたいくらい 2025-12-26 21:21:21

和歌山は今の横浜になってる すさみ町が湘南になり、 新宮が鎌倉になり、 湯浅醤油が覇権を握る

はじめに こんにちは、和田です。いえらぶGROUPで開発部の執行役員を務めています。 弊社も例に漏れず、今年はAI活用に非常に注力してきました。Cursorを全エンジニアに導入し、テックリードにはClaude Codeを配布、業務効率化・実装スピード強化・精度向上を進めてきました。 そんな会社で、私はある新人エンジニアに対して「AIの使用を禁止する」という判断を下しました。 先日ちょっと話題になってましたね、こちらの彼の話です。 社内でも圧倒的なAI推進派の私がなぜそのような判断をしたのか。そして3ヶ月後、その新人はどう変わったのか。この記事では、私の目線からのある種答え合わせ的なつもりで経緯と結果をまとめてみました。 最初は「AIをどんどん使わせていた」 新人が入社した当初、私は彼にもCursorを使わせていました。なんならClaude Codeも使わせていました。理由はシンプルです。

はじめに 「論理削除？deleted_atカラム追加すればいいでしょ」この一言から始まる地獄を、何度見てきただろうか。 最初は簡単に見える。カラムを1つ追加するだけ。しかし、その「簡単さ」こそが罠だ。 論理削除は技術的負債の温床だ。WHERE句への条件追加忘れ、認知コストの増大、テストの複雑化、パフォーマンス劣化。すべては「最初にドメインを考えなかった」ツケである。 しかし現実として、サービスを運用していくと論理削除が必要になる場面は確実に訪れる。 論理削除の本質は、「このレコードは存在するが、存在しないことにしてほしい」という矛盾だ。この矛盾を解消するか、受け入れて安全に管理するか。本記事ではその両方のアプローチを解説する。 なお、私はDBのスペシャリストではないので、ここで紹介する方法が唯一の正解というわけではない。あくまで一つのアプローチとして参考にしてほしい。データベース設計は文脈

これはdesigning plus nine Advent Calendar 11日目の記事です。 こんにちは。ritarと申します。 Slackに昨年追加された「キャッチアップ」という機能がめちゃめちゃ便利で毎日使っているのですが、ご存知ですか？ 各チャンネルがカードになっている。右にスワイプすると既読にできるSlackには、メッセージを送れる「チャンネル」が多数あり、それぞれで独立した会話が起こります。 普通は、「チャンネル一覧」から一つずつ開いて、その中に届いている新着メッセージを読みます。しかし、大きい組織だとどんどんチャンネルが増えていき、既読をつけるのが大変になります。 そこで導入されたのがキャッチアップです。この画面では各チャンネルがカードになっており、それを左右にスワイプしていくことで、既読にするか未読にするかを選ぶことができます。 何も考えずにただ左右にスワイプしていくだ

この記事は、Linc'well Advent Calendar 2025 15日目の記事です。 昨日は mani3 さんの「Amazon Cognito のユーザプール一意化するときに気をつけたいこと」でした。 今回は O’Reilly のサブスクで読める Domain-Driven Transformation という本を読んだので、 その本の感想と学びを書きたいと思います。 この本は、DDD の設計解説がメインではなく、 システムを“壊さずに”どのように変革していくか にフォーカスした内容です。 🔄 システム刷新がうまくいかなくなる理由 システム刷新をどう進めるかを考えるとき、 振り返ってみると、失敗しやすいパターンにはいくつか共通点があるように感じます。 先に「理想のアーキテクチャ」だけを決めてしまう 現場の業務理解が追いついていない チーム構成が旧システム前提のまま 「完成後に一

以下、プレスリリースの全文を掲載しています リアルな月面探索シミュレーター「REAL MOON」12月16日より無料でリリース。ヒストリアとJAXAの共同研究による月面シミュレーション環境を利用。 Unreal Engine （以下、UE）専門のソフトウェア開発会社 株式会社ヒストリアは、観測データや論文を基に作られたリアルな月面シミュレーション探索ゲーム「REAL MOON」を本日2025年12月16日にSteamにて無料で公開しました。 本作の月面地形は、国立研究開発法人宇宙航空研究開発機構（JAXA）とヒストリアによる共同研究の成果物を利用し、精度の高い“リアルな月面”を再現しています。 Steamページ：https://store.steampowered.com/app/4143610/REAL_MOON/ PV：https://youtu.be/aAkuMXQPMPI?si=o

Metaが音声分離AI「SAM Audio」を公開しました。SAM Audioには音声や動画を入力可能で、「文章で指示して特定の音を抜き出す」「動画内の『音声を発している被写体』を指定して音声を抜き出す」「動画内の特定のタイミングで鳴っている音を指定して抜き出す」といった操作が可能です。 SAM Audio https://ai.meta.com/samaudio/ Introducing SAM Audio: The First Unified Multimodal Model for Audio Separation | AI at Meta - YouTube SAM Audioは音声だけでなく動画も入力することが可能です。音楽セッションを記録した動画からギターの音だけを抜き出したい場合は、テキストで「guitar」と指示します。 これで動画内のギターの音だけを分離できます。 動画内

人を集めただけでは、チームにはならない。 人が足りないからでも、能力が足りないからでも、モチベーションが低いからでもない。多くの場合、人と人のあいだに、行動を結びつける関係性が立ち上がっていないからだ。 人は同じ現実を見ていない 同じ組織にいて、同じ会議に出て、同じ資料を読んでいても、人は必ずしも同じ現実を見ているわけではない。何が起きているのか、何が問題なのか、何を優先すべきなのか、そうした認識は各人の経験や立場によって自然と形づくられる。そのため、同じ出来事を前にしても、人によって見えているポイントや意味づけは少しずつ異なる。 ただ人を集めただけの状態では、それぞれが異なる前提や認識を抱えたまま同じ組織に存在しているだけになり、チームにはならない。 チームが機能しているときに起きていること チームが機能しているとき、メンバーは自分の作業内容だけを見ているわけではない。なぜそれを今やって

この記事は、 NTT docomo Business Advent Calendar 2025 の15日目の記事です。 皆さまどうもこんにちは、@strinsert1Na という人です。以前は株式会社エヌ・エフ・ラボラトリーズという会社に出向しながらバリバリ「脅威インテリジェンス」のお仕事をしておりまして、今年の7月からはNTTドコモビジネス 情報セキュリティ部の管理職として新たなキャリアを歩んでおります。 ここまで書くと「なんだ、ただの順調にキャリア形成している人のめでたい話か」と思われてしまいそうですが、そんなことはありません。正直なところ、ほぼ毎日「(あんなやり方でよかったんだろうか…)」という不安の言葉が頭の中を駆け巡るような日々を過ごしており、半年経過した現在でもプレイヤーと管理職のロール/責任の違いにてんてこまいな状態です。 この記事では、社会人人生をずっと”エンジニア(プレイ

MOSHでソフトウェアエンジニアをしている masuyama です。 この記事はMOSHアドベントカレンダー13日目の記事です。 本日はネタ枠なので、気楽に読んでください。 前置き 今年はドラクエ1, 2がリメイクされました。中学生のころ、ドラクエ1を友達の家で、ドラクエ2を駄菓子屋据え置きのファミコン[1]でプレイしたのを思い出します[2]。ドラクエ1の発売年は1986年で、もう39年前になります。当時のROMの容量は512kbit[3]ということですが、今このサイズでプログラムを組めと言われたら頭を抱えるしかありません。 ソフトウェアを取り巻く環境はそのころとは格段に変わり、今もAIなどによって変わり続けています。昨年は身体的なところを取り上げてきましたが、今年はややメンタル寄りの変化とその付き合い方をピックアップしていきたいと思います。 ※内容はあくまでも個人の感想です。 ちなみに去

はじめに 本記事は、Luup Advent Calendar 2025の12日目の記事になります。 こんにちは、株式会社LuupのSoftware部でPlatform / Technology Enabling (Backend TL) を担当している安元（やっすー）です。 終わらない議論に終止符を打つ 「このコード、リファクタリングしないと将来まずいです...😖」 「でも、それでお金は稼げるの？ ユーザーに何か価値があるの？🤔」 「システムのリプレースが必要なので、機能開発を数ヶ月止めさせてください🥶」 エンジニアとビジネスサイド（経営層・PM）の間で、どの企業でも幾度となく繰り返されてきた会話かと思います。お互いの「スタンス」の違いから生じる、自然かつ不幸なすれ違いではないでしょうか。 この記事の目的は、なぜアーキテクチャ改善やマイクロサービス化のような保守性向上を行うのかという