こんにちは。2025年9月にSmartHRへ入社したプロダクトエンジニアのicchanです。 現在はAIインテグレーションユニットで、生成AIを活用した社内問い合わせ対応の効率化に取り組んでいます。 本記事では、社内問い合わせBotの改善プロセスで実践した「2段階DSPy」というアプローチについて解説します。 TL;DR 本記事の要点は次の通りです。 オンライン指標（Good/Bad/Copy）は「正解」に近いが、フィードバックが遅くノイズが多いため、開発のループを回しにくい そこで、オンライン指標を教師データにして、DSPyで「オフライン評価器（Judgeプロンプト）」を学習させ、"高速に実験を回せる物差し"を作った さらに、その物差しを評価関数に組み込み、生成プロンプト自体をDSPy（GEPA）で最適化することで、ユーザーの実感に即した改善を自動化した flowchart LR sub

こんにちは、LayerXのバクラク事業部 AI BPOチームでエンジニアをしているikehara (@ikehara_dev)です。 この記事は LayerX Tech Advent Calendar 2025 19日目の記事です。 本記事では、推論（Reasoning）モデルgpt-5-miniを本番投入した際の事例を紹介します。 当初は推論レイテンシが想定上限に達し、運用が厳しい状態でした。そこから「推論パラメータ調整」と「プロンプトエンジニアリング」を行い、精度を落とさずにレイテンシを改善した方法を、試行錯誤の過程を交えて解説します。 TL;DR gpt-5-mini を本番投入したらレイテンシが厳しくなったため、推論パラメータとプロンプトを見直した reasoning_effort をmedium→low にするだけで40%高速化（15.4秒→9.2秒） プロンプトは 「手順(Ho

に触発されて、今後の未来予測を書いていく。 AIのコードは洗練され、人間のコードレビューが物理的に無理になる の記事にあったように、現状まだ酷いコードを生成することが多い。 自分もここ1年を振り返るとAIが生成したコードからクラスを切り出してることが多かったように思う。 ただそれもおそらく2026年にはだいぶ洗練されるのではないかと予想している。 画像生成AIが気づいたら指6本画像を生成しなくなったように。 そうなってくると、いよいよボトルネックになるのは人間のコードレビューだ。 現状でも既にコードレビュー結構しんどいのに、今後仮に毎日100万行のコードが生成される世界になるとすると、1日8時間稼働として、1時間で約12万行 読まないといけなくなる。 いやいや、1時間に12万行って単にニュース記事を読むのでも無理。 ってか8時間ひたすらコードレビューするの自体無理。 そして土日もコード生成

情報処理技術者試験が大きく変わる。応用情報技術者試験と高度試験を「プロフェッショナルデジタルスキル試験」として3領域・3試験に再編する他、非エンジニアがITパスポート試験の次に受けるべき試験として「データマネジメント試験（仮称）」を新設する。経済産業省が2025年12月、見直しの検討案を発表した。 「デジタル技術の大きな変化に対応するため、幅広い知識やスキルの習得につながる体系への見直しを検討している。高度試験については、これまでは目指す人材像に応じた体系だったが、（習得）スキルをベースとしたものにしていきたい」。経産省の枝川慶彦商務情報政策局情報技術利用促進課デジタル人材政策室デジタル人材政策企画調整官は、大幅見直しの背景をこう説明する。 見直しの内容は大きく4点だ。

20251219 OpenIDファウンデーション・ジャパン紹介 / OpenID Foundation Japan Intro

はじめに 統計検定1級取得後も学び続ける必要性を感じた背景 私は，製造業のデータ分析チームでリーダーをしている，データ分析の実務家・中間管理職である。 2023年に統計検定1級を取ったが，AI・データサイエンス分野の進化が激しく，普段の業務でデータ分析の手法を間違えずに使っていくためには，基礎と応用の両面を統計検定1級取得後も学び続ける必要があると感じた。 この記事を書く目的 これまでは，読書した後にノートにメモを残していたが，読み返したり検索したりするうえで電子化が必要だと感じた。また，統計検定1級を目指したり，私のような悩みを抱えている方の参考になるかもしれないと思ったりしたため，ブログを読書メモに書くこととした。 これまで作成した読書メモ一覧がかなり増えてきたため，2026年1月現在の情報をもとに，いったん数理統計・データサイエンスのおすすめ書籍ガイドにまとめることとした。なお，主観

これは個人の見解です。この話題に関する意見が人によって違うことは理解していますが、あくまで私1人の意見として参考にしてください。 何事にも批判的思考を持つことが大切という話です。 TL;DR 現代的な環境にデプロイする場合、RDBは非常にコストが悪い。 全開発者がエンタープライズクラスの信頼性が必要な高予算Webシステムを開発している訳ではない。 代わりにMongoDB（やその他ドキュメントDB）を使うことで、無料枠で収めることができる場合があり、そのような目的でトレードオフを理解した上でドキュメントDBを選択するのは合理的な選択肢である。 RDBは高い RedditやTwitterでMongoDBをRDB（リレーショナルデータベース）の代わりに使うことを馬鹿にするミームをよく見ます。確かにほとんどのWebシステムではMongoDBより一般的なRDBの方が適していることがほとんどです。We

2025 年も色々やりましたので活動を振り返ります。 目次 目次 研究 Solving the Cold Start Problem on One's Own as an End User via Preference Transfer（エンドユーザー自身が嗜好転移によりコールドスタート問題を自力で解決する） Influential Bandits: Pulling an Arm May Change the Environment（影響バンディット：アームを引くと環境が変わるかもしれない） Interestingness First Classifiers（面白さ優先分類器） Fast EXP3 Algorithms（高速な EXP3 アルゴリズム） ブログ 人間には認知できない情報を活用するAIたち 絶対に分かる機械学習理論 言語モデルの物理学 アンナ・カレーニナの法則と真理に収束して

こんにちは。Algomaticの大塚です。 今回はDifyやn8nといったAIアプリケーションのWorkFlowを自動で作成する取り組みをご紹介します。 はじめに：ノーコードツールの限界 Dify、n8nといったノーコードツールは非エンジニアでも触れる点がプログラミングとの違いと言われています。しかし、実務の観点から見ると状況は異なります。 プロンプトを1行変更するだけでも、GUIの操作手順を覚える必要がある 作ったWorkFlowのテストは手動でやるしかない エラーが起きたら、どこが悪いのか特定するのに時間がかかる 結局、非エンジニアでも触れるはずのツールが、専門知識を持った人しか運用できない矛盾が生まれています。 社内の取り組み そんな課題を解決するために、社内でWorkFlowを自動で生成するシステムを開発しています。このシステムは自然言語からWorkFlowを自動生成するツールです

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

こんにちは！ABEJA に新設されたエンボディドインテリジェンスグループ で PM をしている飯嶌です。 こちらはABEJAアドベントカレンダー2025の24日目の記事です。 昨今、Physical AI への注目が集まっています。しかし、実際に SO-101 などのアームロボットを用いて検証を行おうとすると、組み立ての工数や数万円単位の部材コストが発生し、ハードルが高いと感じられる方も多いのではないでしょうか。 今回は、toio を活用し、低コストかつ手軽に VLA の検証環境を構築できないか挑戦しましたので、その取り組みについてご紹介いたします。 Physical AI 検証における課題 検証環境と構成 実装・検証 Step 1: 接続テスト - toio.py による制御 Step 2: テレオペレーションの実装 Step 3: 学習と推論 - pushT タスクへの挑戦 まとめ 参

はじめに こんにちは、コーポレートシステム部の坂尾です。コーポレートエンジニアとして社内システムやインフラに関連する設計・開発・運用を担当しています。 はじめに部門について簡単に紹介させていただきます。私が所属するのはコーポレートシステム部という部門で、いわゆる情報システム部門（情シス）です。部のミッションとして掲げているのが「EXをシンプルにする」というものです。EXとはEmployee Experience（従業員体験）のことです。 我々のチームでは生成AIの活用推進や組織的なナレッジの共有に取り組んでいます。今回の記事のテーマは、Sansan MCPサーバーを開発した話です。Sansan MCPサーバーは生成AIがSansanのデータへアクセス可能となるよう設計されたプロダクトです。 本記事では主にSansan MCPサーバーについて技術的なトピックを取り上げ、大きく2つの内容から構

「そろそろ大学院の準備もしないとね」。大学3年の終わり頃のことだっただろうか。周りに勧められるがまま就職セミナーなどに参加していた頃、有志を集めて読書会を開いてくれていた橋本先生が、ふとしたときに私に向けて口にした一言が、きっかけだったように思う。 「大学院」という言葉は、私にはまったく縁のないものであった。家族に大学を出た人は誰もいないし、私自身も、大学に入ったはいいものの、サークル活動——和楽器サークルで箏をひたすら練習していた——に明け暮れていた。たしかに哲学をやりたくて哲学科に入ったのだが、当時はそれほど面白いとも思えず、音楽のほうがずっと楽しいと感じながら日々を過ごしていた。 大学2年生になり、必修科目として設定された哲学を受講しなければならないので、サークル棟から渋々と教室に向かった。その年の講義の担当が橋本先生であった。デカルトの対象的実在性と形相的実在性、スピノザの無限様態

皆さん、DSLを作ることってありますか？ 複雑な設定が可能な社内ツールを作るとき、 「DSLを許容したら自由度が上がって素敵では？」 と思うこと、ありますよね。 私個人としては、エンジニア向けのインタフェースとして、DSLで社内ツールを作ると、作る当時は楽しいものの、複雑なことを許容する分保守性に問題がでてくるデメリットも有り、近年は設定はyamlで書ける範囲にすることが多いです。 一方で、非エンジニア向けに、ロジックをビジュアルなDSLで提供できたら良いなってこともありませんか。 例えばjoinとfilterのみに絞ったデータ集計ツールを作りたい、行動Aをしたあとに行動Bをした一部のユーザーにキャンペーンメールを送りたい、などのロジックを安全にかつ柔軟に提供したいというシーンです。 ビジュアルで書けるって範囲にすれば、複雑度も一定の範囲になるのでありかなと思ってます。 こういう、ロジック

Datasetteの開発者であるソフトウェアエンジニアのサイモン・ウィリソン氏が、ソフトウェア開発においてAIに丸投げすることがダメな理由を解説しています。 Your job is to deliver code you have proven to work https://simonwillison.net/2025/Dec/18/code-proven-to-work/ 生成AIの普及により、Microsoft製品のコードの30％はAIで書かれていたり、開発者の92％がAIコーディングツールを愛用していたりと、ソフトウェア開発の世界にもAIは着々と浸透しつつあります。 しかし、何かしらのAIツールを利用する権限を与えられた若手エンジニアが、AIを用いてソフトウェア開発を行ない、動作テストなどをコードレビュープロセスに丸投げするケースがあるそうです。このような行為について、ウィリソン氏

Anthropic、AIエージェントにタスクの手順や知識を組み込める「Agent Skills」をオープンスタンダードに。早くもVS CodeやCursorなどがサポート Anthropicは、同社のAIサービス「Claude」が備えてきた機能「Skills」を業界のオープンスタンダードにすべく「Agent Skills」仕様の公開を発表しました。 Agent Skillsは、AIエージェントにタスクごとの手順や知識を組み込むための仕組みです。 繰り返し行うタスクなどをAIエージェントに依頼する場合、あらかじめAIエージェントにAgent Skillsを読み込ませておくと、毎回細かな指示を行わなくてもAgent Skillsに設定しておいた手順や知識を元に作業をしてくれます。 ソフトウェア開発の場面では、例えば社内のビルドやテストの手順などをAgent Skillsに設定しておけば、AIエ

【画像】つらい闘病も…漫画家・鹿子さん訃報全文 鹿子さんは以前から闘病中で、今年10月27日に同作の連載について「昨年末、他臓器への転移が確認され、これまでなんとか治療と連載を両立してきましたが今回治療に専念するため不定期連載にさせて頂くという判断に至りました」と伝えていた。 そんな中で今回、編集部は「『満州アヘンスクワッド』の漫画担当である鹿子先生が2025年11月8日に脈絡膜悪性黒色腫のためご逝去されました。37歳でした。鹿子先生の素晴らしいご活躍に感謝と敬意を表すると共に、心よりご冥福をお祈りいたします」と報告した。 今後の掲載については「鹿子先生からは生前に『自分の身に何かあった場合は代筆の方を立てて物語を完結させてほしい』という言葉を預かっておりました。代筆をお願いする方については未定ですが、編集部として鹿子先生の想いを継ぎ『満州アヘンスクワッド』を完結まで導いていく所存です。今