https://aiau.connpass.com/event/365588/
MCPの認証と認可 - MCP Meetup Tokyo 2025
https://aiau.connpass.com/event/365588/
なぜLambdaから直接他のLambdaを呼び出すのはアンチパターンなのか - Qiita
はじめに 皆さんは、あるLambda関数から他のLambda関数を呼び出したいときはどうしますでしょうか。本記事ではアンチパターンとその解決策を紹介します。 結論 一般的にはLambda関数内で他Lambda関数を呼ぶ（invoke）のはアンチパターンとされている Lambdaから他のLambda関数を呼び出したい場合は「SQS」または「Step Functions」等を利用する アンチパターンであることを理解した上であれば、直接Lambda関数を呼ぶことを否定するものではない 単純な処理であれば有用なケースもあり得る LambdaからLambdaを呼ぶことの問題点 ここが話の本題になります。まずは雑に2つのLambda関数を用意しました。Hello Worldを出力するlambda_callee.pyと、そのLambda関数を呼び出すlambda_caller.pyという関数です。lam
初めて質問させていただきます。 パスキーの仕組みについてわからないことがあります。 巷で解説されているパスキー認証の仕組みサイトを読むと、 ①サーバーからデバイスにチャレンジが送られる ②デバイスが秘密鍵でチャレンジに署名をして送り返す ③サーバーが署名を公開鍵で復号してチャレンジと同じか検証する というような事が書かれています。 そしてその仕組みは「公開鍵暗号方式」が使われていると書かれています。 けれども、基本情報技術者の教科書を読むと、公開鍵暗号方式は ①受信者の公開鍵で暗号化し ②受信者の秘密鍵で
初めて質問させていただきます。 パスキーの仕組みについてわからないことがあります。 巷で解説されているパスキー認証の仕組みサイトを読むと、 ①サーバーからデバイスにチャレンジが送られる ②デバイスが秘密鍵でチャレンジに署名をして送り返す ③サーバーが署名を公開鍵で復号してチャレンジと同じか検証する というような事が書かれています。 そしてその仕組みは「公開鍵暗号方式」が使われていると書かれています。 けれども、基本情報技術者の教科書を読むと、公開鍵暗号方式は ①受信者の公開鍵で暗号化し ②受信者の秘密鍵で復号する とあります。 過去問を見てもそれ以外はすべて誤りです。 件のパスキーの説明サイトの流れは、どちらかというとデジタル署名の鍵の組合せだと思います。 パスキーの様に、先に秘密鍵で暗号化し、あとで受信者が公開鍵で復号化する場合も つまり公開鍵を使った仕組み(PKIに支えられた仕組み)は
手触り感のあるContext Engineering - LayerX エンジニアブログ
こちらはLayerX AI エージェントブログリレー2日目の記事です（1日目のponさんの怒涛のTKG記事（not Tamago kake gohan）もぜひご覧ください）。 こんにちは、CEO室でAI Agent開発のPdMをやっているKenta Watanabeです。 近年のLLM関連技術の急速な発達により、自社プロダクトの開発にLLMを活用する方も増えてきているのではないかと思います。一方で、LLMの確率的な振る舞いからプロダクションで安定稼働する機能やAI Agentの開発に苦戦している方も同時に多いのではないかと思います。 そういった中で、6月頃からContext Engineeringと呼ばれるLLMをうまく稼働させるための技術が話題になってきました。Context Engineeringというキーワードがバズり出した起源やContext Engineering自体の解説は各所
Claude Codeのサブエージェントを使ってプロジェクトに合わせたcommit messageを作る - $shibayu36->blog;
Claude Codeを使って開発していると、生成されるcommit messageが冗長すぎるという問題に直面する。最近リリースされたサブエージェント機能を使うとこの問題を解決できたので、その方法を共有する。 Claude Codeのcommit messageの課題 Claude Codeのセッションで実装が終わったときに git commit を実行させると、以下のようなめちゃくちゃ冗長なcommit messageが生成される。 Add describe_tables e2e test and refactor MCP initialization - Add comprehensive e2e test for describe_tables tool - Refactor MCP server initialization into reusable functions - s
チャットコミュニケーションでの不満の表明は悪手 - Konifar's ZATSU
今は全くやらなくなったが、チャットコミュニケーションでなんだか憤りを感じた時に "お気持ち" をガッと文章で書いてしまっていたことがある。 この振る舞いは物事を前に進める上では悪手でしかないと思っていて、そんな感じのことを雑につらつらと書いておきたい。 自分の経験上、チャットコミュニケーションで「お言葉ですが」とか「気持ちだけ書いておくと」とか「ちょっと言っておきたいんですが」みたいな感じで自分の不満をテキストで表明するのは悪手。ここまで露骨ではないにせよ、ちょっと非協力的になって"拗ねた"り、線引きして突き放したりするような物言いをするとかもこれに含まれる。 やっちゃダメとまでは言わないけれど、建設的に物事が進むことは少ない。もし進んだとしたら、それは不満を表明した自分のおかげではなく噛み砕いて軌道修正してくれた相手やまわりのおかげ。勘違いしてはいけない。 「そうは言ってもきちんと明確に
大吉祥寺.pm 2025に行ってきました - $shibayu36->blog;
大吉祥寺.pm 2025に行ってきた。今回は前夜祭&懇親会、本編&懇親会&ナイトパーティと、すべてに参加して楽しみ切ってきた！ 発表として印象に残ったのは、yoku0825さん、sotarokさん、nrsさんの3人の発表だった。 まずyoku0825さんの「2025年になってもまだMySQLが好き」は、MariaDBとMySQLって単にforkされた似たものだと自分が思っていた無知を打ち砕かれる発表だった。logfileがMariaDBだと一本になってしまってあまりにも追記が早いとクラッシュするというのも面白すぎる。発表から「本当にMySQLが好きなんだな」という熱量を感じられてとても良かった。 sotarokさんの「大個人開発サービス時代にプラットフォームはどう生きるか」も印象に残った。Vibe Codingが出始めてから、自分もめちゃくちゃ個人開発が楽しいのでとても共感した。個人サービ
提案レベルを上げてみたら、私の『提案』が『進捗』になっていた件
「なんでこの提案、通らないんだろう？」 ──かつての私は、仕事が進まない理由を“相手”に求めていました。 しかしあるとき気づいたのです。提案が止まるのは、「言語化」を相手に委ねていたからだと。 提案レベルを上げ、“伝えたい”を“伝わる”に変えるための言語化コストを自ら引き受けることで、提案はそのま…
「前にも言ったけど」を言わない技術 - プププなテクブ
コミュニケーションで1番重要なことはなんだろう？ 「自分が何を伝えたか？」は大前提として「相手に何が伝わったか？」ではないだろうか。なので、「前にも言ったけど」を言ってしまうとき、往々にしてこの原則が守られていない。 かのアイルランドの劇作家、バーナード・ショーは「コミュニケーションにおける最大の問題は、それが達成されたという幻想である」という言葉を残している。 「前にも言ったけど」という枕詞は相手にストレスをかけるだけだ。本質であるコミュニケーションの改善には寄与しない。むしろ悪化させるだけだ。日常的に発していることに心当たりがあるのなら、そのスタンスを見直す必要がある。 そのために心がけていることを話す。 自分の心の持ち方を変える 「前にも言ったけど」と言いたくなるのは、相手が覚えていないことへの苛立ちや、自分の説明コストが重なっていると感じているからだ。この感情とうまく付き合うために
Nx の攻撃から学べること #s1ngularity | blog.jxck.io
Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a
「レガシーコードを任されるのは、エンジニアにとって光栄なこと」30年以上も依頼が途切れない、uzullaの仕事術 - Findy Engineer Lab
ソフトウェアエンジニアには、多種多様なキャリア戦略があります。組織に長く所属し、信頼を積み重ねて中核を担う人もいれば、「あの技術なら、あの人」と評されるほど特定分野に特化する道もあるでしょう。そんな中、「流しのエンジニア」として活動し、企業からの依頼を受けては数々の現場の課題を解決してきた仕事人がいます。 彼の名はuzullaさん。PHPカンファレンスやPHPerKaigi、YAPCなどで数多く登壇しており、エンジニアコミュニティ内で広く知られる存在です。uzullaさんは学生時代からエンジニアとして働き始め、以来30年以上、仕事が途切れたことがありません。では、どんなスキルを磨けば「指名されるエンジニア」になれるのでしょうか。その秘訣を聞きました。 技術力や知名度以上に大切なのは、信用されること ――uzullaさんが「クライアント企業から問い合わせを受けて、案件を受託する」という働き方
AIでSlackから歴史的経緯を追いかけやすくしよう - slack-explorer-mcpを作った - $shibayu36->blog;
エンジニアリングをしていると、「なぜ現在こうなっているか」について調べたくなることがよくある。コードを読んでも、なぜその設計判断がされたのか、なぜその仕様になっているのかが分からないことが多い。 歴史的経緯はコミットログ、GitHub Pull Request、Slackでの議論などに残っていることが多い。これらの情報を組み合わせることで、コードには表れない設計判断の背景や仕様決定の経緯、トラブルシューティングの過程などを発見できる。 しかし、Slackから過去の議論を探すのは結構大変だ。なぜなら 解決のための適切な検索クエリを見つけるのが大変 検索結果から今ほしい情報を見つけるのが大変 AIを活用しようにも、コミットログやGitHub Pull Requestと違い、Slackの情報をAIエージェントが直接扱えるやり方が少ない そこでAIエージェントを使って歴史的経緯を発見しやすくするた
「推論する生成AI」は実際には思考しているわけではなく、丸暗記した結果を返しているに過ぎない - 渋谷駅前で働くデータサイエンティストのブログ
今回のテーマは以前からずっと言われ続けている話題なので特に目新しくも何ともないのですが、たまたま近い時期に2本の似通った内容の論文がarXivに出たので、まとめてダイジェスト的に紹介しようと思います。以下がそれらの論文です。1本目はApple、2本目はGoogle DeepMindによる研究です。 どちらもSNSや技術メディアでは既報の内容であり、ご存知の方も多いのではないでしょうか。これらの論文は本質的には「『推論する生成AI』は実際には思考しているわけではなく、丸暗記した結果を返しているに過ぎない」と各種の実験結果から指摘するものであり、今後の推論生成AIの研究開発を行う上で新たに考慮されるべき指針を提案しています。 そもそも「推論する生成AI」とは何なのか 「推論する生成AI」は既知の複雑な課題は解けるが、その難易度をどんどん上げていくと解けなくなる 逆に、「推論する生成AI」は既知
「推論する生成AI」は事前学習されていない課題を正しく推論することができない（共変量シフトに弱い） - 渋谷駅前で働くデータサイエンティストのブログ
先日の記事で「CoTを用いて『推論』する生成AI」の「推論」能力の限界について、論文2点を挙げて論じたところ思いの外反響が大きくてちょっとびっくりしたのでした。 なのですが、最近になって同じテーマに対して「厳密に条件統制されたデータセットを用いてLLMを実際に構築した上で実験した」という論文が出てきたとのことで、ちょっと読んでみました。それがこちらです。 実のところ、読んでみたらかなり技巧的かつ綿密に設計された内容の論文で当初一読した範囲では理解し切れない感じがありました。なのですが、非常に興味深い内容だったのと、その検証手法が斬新だったということもあり、このブログでは珍しいことですが2回連続で論文紹介をしてみようと思います*1。なおいつもながらですが、記事中に理解不足や認識の誤りなどの箇所がありましたら何なりとご指摘くだされば幸いです。 巧みな実験設計：CoT推論に影響し得る「3つの次元
【Docker】docker.service, docker.socketで大ハマりした話 - Qiita
はじめに AWS EC2インスタンス内のDockerで立ち上げたWebアプリのcurlエラーの解決に苦戦したので備忘録を残します。 docker.socketの話だけ読みたい方は、背景を読み飛ばしてください。 背景 curl: (56) Recv failure: Connection reset by peer が1か月以上解決しなかった話 docker内のFlaskで実装したAPIをEC2のcurlで定時実行させようとしたところ上記エラーが発生しました。また、1度curlを実行した後、再度実行するとうまくcurlが実行されました。 当時の状況 EC2インスタンス起動時 docker.service：自動起動しない（preset; disabledになっている） docker.socket：自動起動する（preset; enableになっている） Flaskが反応しなかった理由 dock
LLMとソフトウェア開発に関する考察 - Martin Fowler's Bliki (ja)
私はこれから数週間、このサイトの管理を離れる予定だ（半分は休暇、半分は仕事）。日々のルーティンから離れることを考えているうちに、LLMやAIの現状について、散漫な考えを共有したいと思った。 AIがソフトウェア開発に与える影響についての初期の調査をいくつか目にした。生産性は向上しているのか？コードの品質は上がったのか？下がったのか？などである。こうした調査の大きな問題は、LLMの使い方を考慮していない点だ。私が知る限り、LLMの使い方の大半は（主にco-pilotを使用した）「高機能なオートコンプリート」である。だが、LLMを使いこなしている私の知人たちは、オートコンプリートはあまり役立たないと考えており、LLMにソースコードのファイルの読み込みと編集を許可し、タスクを実行させるアプローチを好んでいる。LLMの使い方を無視した調査は、誤った方向へ人々を導くデータを生み出すのではないかと懸念し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか」というタイトルでDevelopersIO 2025 Osakaに登壇しました #devio2025 | DevelopersIO
大「個人開発サービス」時代に僕たちはどう生きるか
定義のない仕事 / Undefined Work
2025年になってもまだMySQLが好き
