株式会社ずんだもん技術室AI放送局

AWSはre:Inventカンファレンスにおいて、生成AIアプリケーション構築・拡張のためのフルマネージドサービスであるAmazon Bedrockの機能強化を発表しました。主な強化点は以下の3点です。

Automated Reasoning checks: 生成AIモデルの「幻覚（hallucination）」と呼ばれる、事実と異なる回答を生成してしまう問題に対処する、業界初のセーフガードです。論理的に正確で検証可能な推論を用いて、モデルの回答の正確性を検証し、監査可能な出力と推論過程を提供します。これにより、医療、金融、政府機関など、正確性が極めて重要な分野での生成AI活用が促進されます。PwCは、この機能を活用して、高精度で信頼性の高いAIアシスタントを構築しています。

マルチエージェント連携: 複数のAIエージェントを容易に構築・調整し、複雑なタスクを共同で解決できるようにします。単一のAIエージェントでは困難な、大量のデータ分析や複雑なワークフローの自動化が可能になります。金融機関では、デューデリジェンスプロセスにおける複数の専門エージェントの連携による効率化が期待できます。Moody’sは、この機能を用いたリスク分析ワークフローの強化を進めています。

Model Distillation: 大規模モデルの知識を、より小型で効率的なモデルに転送する機能です。元のモデルと比較して最大500%高速化、75%のコスト削減を実現しつつ、精度低下は2%未満に抑えられます。これにより、リアルタイムでのチャットインタラクションなど、低レイテンシと低コストが求められる本番環境での利用に最適なモデルを簡単に作成できます。Robin AIは、この機能を活用して、膨大な契約条項に対する高品質な法的Q&Aを提供しています。

これらの新機能により、Amazon Bedrockは、概念実証から本番環境への移行を迅速化し、生成AIの導入障壁を低くします。既に数万社がAmazon Bedrockを利用しており、その顧客数は過去1年で4.7倍に増加しています。

引用元: https://press.aboutamazon.com/2024/12/aws-strengthens-amazon-bedrock-with-industry-first-ai-safeguard-new-agent-capability-and-model-customization

Googleが提供するGeminiは、アイデアを強化するためのチャットインターフェースです。 ログインが必要です（リンク先： https://accounts.google.com/ServiceLogin?passive=1209600&continue=https://gemini.google.com/app/07b8daed57e45ad9&followup=https://gemini.google.com/app/07b8daed57e45ad9&ec=GAZAkgU）。 Googleアプリと連携して利用できるサービスであり、具体的な機能や使い方は記載されていませんが、その名前から、チャットボットを用いたアイデア創出や作業効率化を支援するツールだと推測できます。 詳細な使用方法については、ログイン後にアプリ内で確認する必要があります。 新人エンジニアの方にとって、アイデア出しや問題解決に役立つ可能性のあるツールと言えるでしょう。

引用元: https://gemini.google.com/app/07b8daed57e45ad9

このドキュメントは、Chrome DevTools の使用方法をスクリーンショット付きで解説したものです。 Lighthouseによるパフォーマンス計測、Performanceタブでの読み込み時間分析、Networkタブでのネットワークリクエストの分析、MainタブでのCPU使用状況の確認、Sourceタブでのリクエストの書き換え、Memory Profilerによるメモリ使用量分析、CSS OverviewsによるCSSセレクタの確認といったDevToolsの主要機能の使い方を詳細に説明しています。

概要:

記事では、Chrome DevToolsを用いたウェブサイトのパフォーマンス分析方法を、多数のスクリーンショットを用いて解説しています。Lighthouseを用いたパフォーマンススコアの計測と解釈、Performanceタブでの読み込み時間とCPU使用状況の分析、Networkタブでのネットワークリクエストの分析、さらに、リクエストの書き換えやメモリ使用量の分析、CSSセレクタの確認方法についても説明しています。 Chrome拡張機能の影響を避けるため、計測時には拡張機能を無効化することを推奨しています。

制約:

解説はChrome 131時点のスクリーンショットに基づいており、UIは今後変更される可能性がある点に注意が必要です。 また、各機能の詳細な意味や理論的な背景については解説されていません。 使用方法に焦点を当てた解説となっています。 Sourceタブでのリクエスト書き換えにおいては、HTTP/2のストリーム処理に影響しパフォーマンスが悪化する可能性がある点も注意書きとして記載されています。 更に、Memory Profilerはスナップショットを複数取得して比較することで有効に活用できることが述べられています。

引用元: https://zenn.dev/mizchi/scraps/c72e6a55deca18

（株式会社ずんだもんは架空の登場組織です）

イーロン・マスク氏がOpenAIとマイクロソフトを相手取り、独禁法違反で差止命令を求める訴訟を起こしました。訴訟の目的は、OpenAIの営利企業への転換を阻止することです。マスク氏は今年初めにも、OpenAIが「人類の利益のためにAIを開発する」という設立理念に違反していると主張して訴訟を起こしましたが、数ヶ月後に取り下げています。8月にはカリフォルニア州の連邦裁判所に訴訟を起こしており、今回が3度目の訴訟となります。

今回の訴状では、OpenAIとマイクロソフトが、マスク氏のxAIなどOpenAIの競合他社への投資を阻止するよう投資家に働きかけ、マイクロソフトとの関係を通じて不正に取得した競争上の機密情報や協調行為から利益を得ていると主張しています。 つまり、マスク氏はOpenAIの営利化と、競合他社への不当な妨害を問題視しているのです。 以前の訴訟とは異なり、今回は競合抑制という観点からの訴えとなっており、OpenAIとマイクロソフトの行動が競争環境に与える影響に焦点が当てられています。 日本のエンジニアとして、この訴訟は、AI開発における競争の健全性、そして企業倫理や独占禁止法の重要性を改めて認識させる事例と言えるでしょう。

引用元: https://www.engadget.com/general/the-morning-after-engadget-newsletter-121535788.html

筆者の夫が、GoogleのGemini APIを使ったコンペで受賞しました。約3000件の応募の中から9件が選ばれるという狭き門を突破したとのことです。開発されたアプリは、物体を認識して、被写体の顔にキャラクターを表示させ、会話させるという、動画で確認できるほど魅力的なものです。 デザインも秀逸で、多くの人に受け入れられる見た目になっている点が評価されています。

夫は過去にもGoogleのコンペで受賞経験があり、技術系コンペで好成績を収めることに長けているため、筆者からは「インターネット賞金稼ぎ」と呼ばれているそうです。 このアプリは近いうちにリリース予定とのことです。

なお、筆者自身も生成AIに関する書籍を出版しており、夫婦揃って生成AIに造詣が深いことがわかります。 その書籍は、AIに詳しい「からあげさん」にもネーム確認を受けており、生成AI初心者にも分かりやすい内容になっているとのことです。 書籍の購入はVALUE BOOKS（日本在住者向け）とAmazon（海外在住者向け）から可能です。

引用元: https://www.imagawa.tokyo/entry/2024/12/01/191758

この記事は、長年推奨されてきた複雑なパスワードと定期的な変更というパスワードポリシーが、実は誤っていたという内容です。 この誤ったポリシーが定着した原因として、Unix開発者ケン・トンプソンと暗号学者ロバート・モリスによる1979年の論文「Password Security: A Case History」が大きく影響したと指摘しています。

この論文は、パスワードの安全性を高めるために複数の文字種（小文字、大文字、数字、記号）を含む複雑なパスワードを推奨しました。しかし、実際には「p@ssword」のような推測しやすいパターンも多く、セキュリティ向上には繋がっていないことが現在では明らかになっています。

さらに、論文ではパスワードをハッシュ化して保存する方法が提案されました。この方法は、研究者によるパスワードの実態調査を困難にし、パスワードに関する知見の蓄積を停滞させる結果を招きました。

つまり、一見有効に思えたこの論文の推奨事項が、長年に渡りパスワードセキュリティの向上を阻害してきたというわけです。 NIST SP 800-63ガイドラインの改訂によって、「パスワードは複雑さより長さ」という考え方が主流になりつつありますが、この歴史的背景を知ることで、セキュリティポリシー策定の難しさや、一見正しいと思える施策の長期的な影響を考慮する重要性を改めて認識できます。 この記事は、過去の偉大な科学者たちの誤りから、セキュリティ対策を考える上で重要な教訓を与えてくれています。

引用元: https://yamdas.hatenablog.com/entry/20241202/bad-password-policies

ある市役所の職員がChatGPTを用いてシステム開発を行い、外注費用の30分の1のコストで開発を完了したというニュースが話題になっています。しかし、この事例を受けて、多くの市長や社長が同様の取り組みを検討していることに対し、警告を発する声が上がっています。

この事例は、素人によるDIYのようなものであり、システム開発における専門知識や経験が不足している場合、大きなリスクを伴うことを示唆しています。具体的には、以下のような問題点が指摘されています。

多くのエンジニアは、ChatGPTなどの生成AIは開発を支援するツールとして有用である一方で、それだけでシステム開発を行うことは危険だと指摘しています。 システムの品質、セキュリティ、保守性などを十分に考慮した上で、責任ある開発体制を構築することが重要です。 コスト削減を優先するあまり、リスクを軽視して安易にChatGPTを利用することは、かえって大きな損失につながる可能性があります。 この事例は、ChatGPTの利用には専門的な知識と理解、そして自己責任が不可欠であることを改めて示しています。

引用元: https://togetter.com/li/2474058

（株式会社ずんだもんは架空の登場組織です）

KyashのVP of Engineeringとして2022年1月から開発組織のマネジメントに携わり、2024年1月から執行役員に就任した著者が、その1年間を振り返る記事です。

当初は役割の変化は少ないと考えていましたが、想像以上に変化がありました。Kyashの事業は決済ユーザー数の増加と事業全体の収益性改善という成果を上げており、B2B領域の法人送金サービスの立ち上げも成功しています。しかし、著者は自身の貢献度を低く評価しており、「自分は何をすべきか」「事業成長にどう貢献できるのか」という疑問を抱くようになりました。

執行役員になったことで、周囲からの期待や見られ方が変化したことを実感します。「役員としての意見ですか？」と問われたり、「konifarさんが役員になって何か変わりましたっけ？」と問われたりした経験から、自分の発言がどう捉えられるかを意識するようになり、成果を出すことの重要性を再認識しました。

経営会議への参加を通して、会社全体の収益やコスト構造を理解するようになりましたが、議論を前に進めるような行動はできていませんでした。また、多くの業務を自ら担っている現状は、役割の委譲ができていないことの表れだと反省しています。

現在は「1年以上先を想像して組織を作っていく」ことをミッションに、組織体制の課題解決や開発生産性向上に取り組んでいます。COOからの「マネジメントはマネジメントにしかできないことをやらないと意味がない」という言葉に背中を押され、採用活動にも力を入れています。

この1年間は試行錯誤の連続で、しんどい時期もありましたが、執行役員という立場だからこそ気づけたことも多くありました。今後は、エンジニアリングの知識・経験を活かし、経営に的確な提案を行うことを目指しています。2025年末まではフルコミットし、最高のプロダクトと組織作りに貢献したいと考えています。現在、Mobile/Serverside/SRE/Dataのポジションを募集しています。

引用元: https://konifar.hatenablog.com/entry/2024/12/01/171150

この記事は、自作キーボードの音響設計に関する考察をまとめたものです。著者は、これまで設計したキーボードの経験から得られた知見に基づき、キーボードの音響特性に影響を与える要素を詳細に分析しています。

キーボードの音は、大きく分けて「衝突音」「主音」「残響音」の3つに分類でき、それぞれ発生源や伝播経路が異なります。衝突音はキースイッチのステムとボトムハウジングの衝突で発生し、スイッチの素材や形状に大きく依存します。主音は、衝突音によって生じた振動がスイッチプレート、PCB、キーキャップなどのパーツに伝播し、それらが空気中に放射することで発生します。残響音は、ケースなどの筐体で音が反響することで発生し、理想的には鳴らない方が良いとされています。

これらの音響特性に影響を与える要素として、以下の点が挙げられています。

著者は、これらの要素を組み合わせることで狙った音を実現できると述べていますが、組み合わせが多いため試行錯誤が必要であると強調しています。 特に、キースイッチとキーボードの相性は重要で、単体で良い音のスイッチでも、特定のキーボードでは好ましくない音になる可能性があります。

最後に、著者が設計したキーボード「Tochka52」の例が紹介されています。Tochka52は、複数の素材を積層したスイッチプレート、木材を組み合わせたPCB構造、ハーフガスケットマウント、真鍮ボトムケースなど、独自の設計思想に基づいて作られています。これにより、「程々に」スイッチの音を鳴らしつつ、オフィスでも使用できるレベルの音量に抑えることを目指しています。 Tochka52の設計では、各パーツの音響特性を考慮し、素材や構造を緻密に調整することで、狙った音を実現しています。

この記事は、自作キーボードの音響設計に携わるエンジニアにとって、非常に参考になる情報が満載です。 各パーツの音響特性への影響、具体的な対策、そして実例を通して、音響設計の複雑さと奥深さを理解することができます。 新人エンジニアにとっても、基礎的な知識から応用的な設計まで学ぶことができる貴重な資料と言えるでしょう。

引用元: https://piroriblog.hatenablog.com/entry/2024/12/01/124054

この記事は、クラウドエンジニアを目指す、または既にクラウドエンジニアとして活躍するエンジニア向けに、技術領域を広げるための学習指針を示したものです。AWSをメインに、著者の経験や業界のトレンドを基に厳選された5つの技術が紹介されています。セキュリティやネットワーク等のインフラ基礎知識は既知と仮定し、開発寄りの技術に焦点を当てています。

5つの技術

IaC (Infrastructure as Code): インフラをコードで管理する技術。Terraform(推奨)、AWS CDK、AWS CloudFormationといったツールが紹介され、Terraformはコードの記述が容易で初心者にもおすすめとされています。GUI操作によるミスを防ぎ、環境複製やバージョン管理を容易にします。

Git: コードの変更履歴を管理するバージョン管理システム。GitHub(推奨)、GitLab、Amazon CodeCatalystといったサービスが紹介され、GitHubは初心者から上級者まで幅広く利用できるとされています。

CI/CD (継続的インテグレーション/継続的デリバリー): 開発からリリースまでの自動化。GitHub Actions(推奨)、AWS CodePipeline、HCP Terraformといったツールが紹介されています。GitHub ActionsはGitHubとの連携が容易なため推奨されています。

コンテナ: アプリケーションとその依存関係をパッケージ化し、環境に依存しない実行を実現する技術。Docker、Kubernetes、Amazon ECS/EKS(推奨)といったサービスが紹介されています。Dockerはコンテナイメージの作成・管理、Kubernetesはコンテナオーケストレーションに用いられます。Amazon ECS/EKSはAWS環境でのコンテナ運用に適しています。

サーバレス: サーバーを意識せずにコードを実行する技術。AWS Lambda(推奨)が紹介されています。サーバー管理の手間が省け、必要な時だけリソースが消費されるためコスト効率が良いです。Pythonがよく使用されるため、プログラミングスキルも必要になります。

記事の後半では、IaC、Git、CI/CDの3つの技術を用いたハンズオンが提供されています。AWSリソースをTerraformで記述し、HCP Terraformを使ってデプロイする手順が、図解付きで丁寧に解説されています。ハンズオンを行うには、GitHub、HCP Terraform、AWSのアカウントが必要となります。

この記事は、クラウドエンジニアとして必要な技術を体系的に学ぶための優れた入門書となっています。ハンズオンを通して実践的にスキルを習得できる点も大きなメリットです。 ただし、紹介されているサービスはAWSに偏っているため、他のクラウド環境についても学習する必要がある点に注意が必要です。

引用元: https://qiita.com/hiyanger/items/ff84c71775f6bc36363b

（株式会社ずんだもんは架空の登場組織です）

食べログの予約サービスチームは、利用者増加に伴う組織拡大により、コミュニケーションコスト増大、情報伝達の遅れ、開発スピードの遅延といった課題に直面していました。 これらの課題解決のため、チームは組織編成と情報共有方法に工夫を凝らしました。

まず、2名のエンジニアリングマネージャー(EM)と、複数の小チーム（ユニット）からなるユニット制を採用しました。 EMはそれぞれ異なる領域（運用・改善、プロダクト開発）を担当し、責任範囲を明確化することで、意思決定の迅速化を図りました。 さらに、チームリーダーを配置することで、チーム全体の方針やルールの決定を効率化しました。 ユニットの規模を小さくすることで、リーダーの管理コスト軽減と、リーダーが自ら開発に携われる環境を整備しました。意思決定はボトムアップ型を取り入れ、メンバー、リーダー、マネージャーの各レベルで適切な権限と責任を明確化することで、スピードアップを図りました。

情報共有は、日次と週次の2段階で行われます。 日次では、ボトムアップ型で情報を集約し、重要な課題や意思決定事項を迅速に共有します。 週次では、各ユニットからの情報をEMが集約し、チーム全体に展開することで、チーム全体の状況把握を容易にしました。 他チームとの情報共有は、ユニットリーダーとEMが窓口となり、効率的な情報伝達を実現しています。

今後の展望としては、他チームとのコミュニケーション改善、システムのリモデリングによるドメイン整理、エンジニアリングへの集中を促進するための更なるコミュニケーション改善に取り組むとしています。 これらの取り組みを通じて、開発スピードの向上とエンジニアの生産性向上を目指しています。 本記事は、大規模チームにおける組織設計と情報共有の改善に悩む日本のエンジニアにとって、貴重な参考事例となるでしょう。

引用元: https://tech-blog.tabelog.com/entry/2024/09/tabelog-engineer-information-communication

この記事は、本番DBのマスターデータを誤って全行削除してしまった事例とその反省について記述しています。深夜帯に稼働するSNSサービスにおいて、マスタデータのJSON型カラムを全てブランク値で上書きする作業中に事故が発生しました。原因は、開発環境での動作確認を省略した、UPDATE文によるデータ更新スクリプトの誤作動です。

復旧はRDSのスナップショットからの復元で行われましたが、データ容量が大きかったため1時間程度を要しました。この経験から、以下の反省点が挙げられています。

バックアップの不足: 作業前にSequel ACEによるレコードエクスポートや、CSV形式でのバックアップ（Copy Insert SQL機能活用）を行うべきでした。大量データの場合は、LIMITとOFFSETを使用して分割バックアップが推奨されます。

トランザクションの未活用: START TRANSACTIONとCOMMIT/ROLLBACKによるトランザクション処理を行うべきでした。これにより、更新クエリ実行後のデータ確認を行い、問題なければコミット、問題があればロールバックすることで、データの整合性を確保できます。

スクリプトからの直接クエリ実行: Pythonスクリプトで直接更新SQLを実行する実装は、事故発生時の影響が大きいため避けるべきです。スクリプトはクエリの生成のみとし、実行は手動で行うべきです。

開発環境での動作確認の省略: 過去に同様のスクリプトを使用していたため、開発環境での動作確認を省略しましたが、これは重大なミスでした。時間的制約があっても、開発環境での動作確認は必須です。

この事例は、本番環境での作業におけるリスクと、それを回避するための対策を学ぶ上で非常に貴重な教訓となります。新人エンジニアは、この経験から学び、本番作業前に必ずバックアップを取得し、トランザクション処理を行い、開発環境での動作確認を徹底するよう心がけましょう。

引用元: https://zenn.dev/kazutosakagami/articles/78d1649389c868

Raspberry Pi Compute Module 5 (CM5)がリリースされました。CM4とほぼ同じサイズながら、大幅な性能向上を実現しています。BCM2712 Cortex-A76 64-bit SoCを2.4GHzで動作させ、メモリは2GBから16GB (16GBは2025年以降)、eMMCストレージは8GB、16GB、32GB、64GBのオプションがあります。eMMCストレージを持たないCM5Lite版も存在します。

CM5はRaspberry Pi 5と同じチップを使用しており、性能は向上していますが、高負荷時には発熱も大きくなります。そのため、強制空冷と冷却ヒートシンクの使用、またはモジュールを金属筐体などに熱伝導性良く接続することが推奨されています。

CM4からの変更点として、2レーンCSI-2とDSIポートが削除され、USB 3.0ポートに置き換えられているため、CM4からCM5への置き換えは、ソフトウェアの修正が必要になる可能性があります。特に、BCM270x GPIOレジスタを直接操作している場合は、より多くの作業が必要になります。libgpiodやlibcameraなどの標準ベースのライブラリを使用している場合は、比較的容易に移行できる可能性が高いです。

価格はCM4から若干上昇しており、2GB RAMのCM5Liteが45ドル(税別)、8GB RAM + 64GB eMMCの最上位モデルが95ドルです。開発にはIOボードも必要になります。新しいIOボードには電源ボタン、ファンヘッダ、USB 3.0 Type-Aポートへの切り替えスイッチ、USB-C電源コネクタ、M.2スロット、カメラ/ディスプレイポートが追加されています。HDMIポート、イーサネットポート、GPIOピンなどは引き続き利用可能です。

Raspberry PiはCM5の供給について、発売後も継続的な供給が見込まれると述べています。

引用元: https://www.theregister.com/2024/11/27/raspberry_pi_compute_module_5/

（株式会社ずんだもんは架空の登場組織です）

元Androidのリーダーたちが、AIエージェント向けの「オペレーティングシステム」を開発するスタートアップ企業「/dev/agents」を設立しました。 Googleの元Android製品管理担当副社長であるHugo Barra氏によると、同社はAI業界に「Androidのような革新」をもたらすことを目指しています。

現在、Microsoft、Google、OpenAIなど多くの企業が、自律的にタスクを実行し意思決定を行うAIエージェントの開発に注力しています。しかし、/dev/agentsのCEO兼共同設立者である、Googleの元Androidエンジニアリング担当副社長David Singleton氏は、現状では開発が困難であると指摘しています。

/dev/agentsは、クラウドベースの次世代AIエージェント用OSを開発中で、ユーザーが様々なデバイスで信頼できるエージェントと連携することを目指しています。 Singleton氏によると、AIエージェントには新しいUIパターン、再考されたプライバシーモデル、そして有用なエージェントを簡単に構築できる開発プラットフォームが必要だと述べています。

同社には、Barra氏に加え、MetaでAR/VR担当副社長を務めた元AndroidエンジニアのFicus Kirkpatrick氏（CTO）、ChromeOSのデザインに携わったNicholas Jitkoff氏（最高デザイン責任者）も参加しています。 彼らは、Android開発で培った経験を活かし、AIエージェント開発の課題解決に挑んでいます。 この新しいOSが、AIエージェントの開発と普及に大きな影響を与える可能性があります。

引用元: https://www.theverge.com/2024/11/27/24307525/android-leaders-dev-agents-ai-agent-operating-system-startup

Claude.aiは、ユーザーのニーズに合わせてレスポンスのスタイルをカスタマイズできる機能を発表しました。開発者、マーケター、プロダクトチームなど、様々なユーザーが自身のワークフローに最適化されたレスポンスを得られるようになります。

この機能により、Claudeのレスポンスのトーン、構造、形式を調整できます。プリセットとして、「Formal（フォーマル）」「Concise（簡潔）」「Explanatory（説明的）」の3つのスタイルが用意されています。 「Formal」は洗練された明確なレスポンス、「Concise」は短く直接的なレスポンス、「Explanatory」は新しい概念を学ぶための教育的なレスポンスを提供します。

さらに、ユーザー自身でカスタムスタイルを作成することも可能です。自分の好みのコミュニケーションスタイルを反映したサンプルコンテンツをアップロードし、必要な指示を指定することで、Claudeは独自のスタイルを生成します。 GitLab社のように、ビジネスケースの作成、ユーザー文書の更新、マーケティング資料の作成・翻訳など、様々な場面で一貫したコミュニケーションを維持するために活用できます。

使い方は簡単です。Claude.aiのチャットボックスで、プリセットオプションを選択するか、独自のスタイルをカスタマイズするだけです。 自分の自然な作業スタイルに合わせてClaudeを調整し、生産性を向上させることができます。

引用元: https://www.anthropic.com/news/styles

CNBCの報道によると、ソフトバンクがOpenAIに15億ドルの投資を行うことが発表されました。これは、公開買い付け（テンダーオファー）という形で実施されたものです。 このニュースは、OpenAIの急速な成長と、その将来性への高い期待を示唆しています。 日本のエンジニアの皆さんにとって、このニュースは、AI分野における技術革新のスピード感、そして巨額の資金がどのように最先端技術開発に投入されているのかを理解する上で重要な示唆となります。 OpenAIの技術は、様々な業界で活用されており、今後も更なる発展が期待されるため、この投資は今後のAI技術開発に大きな影響を与える可能性があります。 特に、日本の企業がAI技術を導入・開発していく上でも、この様な大規模投資による技術開発の動向を注視していくことが重要になります。

引用元: https://www.cnbc.com/video/2024/11/27/openai-gets-1-point-5-billion-investment-from-softbank-in-tender-offern-a-tender-offer.html

この記事は、Pingコマンドを用いてネットワーク帯域を計測できるという誤解を解き、正しいネットワーク回線品質の測定方法を解説しています。 多くの技術系メディアでも誤った情報が流布されている現状を指摘し、注意を促しています。

ネットワーク回線の品質は、「帯域（スループット）」「遅延（レイテンシ）」「損失（パケットロス）」「ジッター（ゆらぎ）」の4つの指標で評価されます。Pingコマンドで計測できるのは遅延のみであり、帯域を計測するには不適切です。

Pingコマンドは小さなデータパケットを送信し、応答時間から遅延を測定するシンプルなツールです。 そのため、大量のデータ転送を想定した帯域幅の測定には、データ量が圧倒的に不足しています。また、距離による遅延の影響も無視できません。 単純にデータサイズと時間を用いた計算式では、帯域幅を正確に算出できません。これは、高速道路の通行台数と移動時間で道路の容量を測るようなものです。

正確な帯域幅測定には、iPerfやNanaなどのツールを使用する必要があります。これらのツールは、より多くのデータを送信し、実測値に基づいた正確な帯域幅測定を可能にします。 Pingを用いた帯域測定は誤りであり、信頼できる情報源から正しい知識を得ることが重要です。 新人エンジニアは、これらの指標と測定方法の違いを理解することで、ネットワークパフォーマンスの分析能力を向上させることができます。

引用元: https://qiita.com/keigo_kabutomori/items/1c290a22550542edeff9

（株式会社ずんだもんは架空の登場組織です）

GoogleのシニアプロダクトマネージャーLogan Kilpatrickによるブログ記事では、Gemini 1.5 Pro(画像・動画理解に最適化されたモデル)を用いたマルチモーダル機能の7つの実例が紹介されています。Geminiは、画像・動画だけでなく、長文PDF(1000ページ以上)も理解し処理できます。

主な機能と例:

詳細な画像説明: 画像の内容を詳細に記述し、質問にも回答できます。プロンプトに応じて説明の長さ、トーン、形式を調整可能です。

長文PDFの理解: 1000ページ以上のPDFを理解し、表の転記、複雑なレイアウトの解釈、図表・スケッチ・手書き文字の認識、構造化された出力やコードの生成が可能です。例として、15四半期のAlphabetの収益報告書(152ページ)からGoogleの収益データを抽出し、表を作成し、matplotlibを用いたグラフを作成する例が示されています。

現実世界の文書の推論: レシート、ラベル、看板、メモ、ホワイトボードのスケッチなど、現実世界の文書から情報を抽出し、JSONオブジェクトとして返すことができます。

ウェブページデータの抽出: ウェブページのスクリーンショットからデータ(画像・動画を含む)を抽出し、JSONなどの構造化された形式で出力できます。ウェブデータAPIやブラウジングエージェントなどのアプリケーションに活用できます。Google Playの書籍ページから書籍名、著者、評価、価格をJSON形式で抽出する例が示されています。

物体検出: 画像内の物体を検出し、バウンディングボックス座標を生成します。ユーザー定義の基準に基づいて物体を検索・推論する機能も備えています。

動画の要約と転写: 最大90分の動画を処理し、要約や転写を作成、日常シーンからの構造化データの抽出、質問への回答、重要な箇所の特定などが可能です。技術講義の動画を高校生向けに要約する例が紹介されています。

動画からの情報抽出: 動画から情報を抽出し、リスト、表、JSONオブジェクトなどの構造化された形式で出力できます。小売、交通、ホームセキュリティなどの分野でのエンティティ検出、スクリーン録画からの非構造化データ抽出などに役立ちます。

制約:

動画処理においては、現状1FPSのサンプリングのため、一部情報が欠落する可能性があります。より高いFPSでのサンプリングは今後の開発予定です。

Gemini APIを活用した開発には、開発者ガイドと開発者フォーラムが役立ちます。 様々なユースケースに対応できる強力なマルチモーダル機能を備えていることがわかります。

引用元: https://developers.googleblog.com/en/7-examples-of-geminis-multimodal-capabilities-in-action/

NVIDIAの研究チームが開発した画期的なAIサウンド生成モデル「Fugatto」は、テキストプロンプトだけで音声を生成・変換できる、世界最高レベルの柔軟性を誇るツールです。既存のAIモデルが特定の音声生成や編集に特化しているのに対し、Fugattoは音楽、音声、効果音などを自由に組み合わせ、テキストと音声ファイルの両方から指示を受け付けることができます。

例えば、「悲しい雰囲気のフランス語で話すテキスト」といった複雑な指示にも対応し、アクセントの強さや感情の度合いを細かく調整できます。既存の楽曲に楽器を追加・削除したり、声のアクセントや感情を変えることなども可能です。さらに、既存データにはない全く新しいサウンドも生成できます。例えば、トランペットが吠えたり、サックスが鳴き声をあげたりといった、想像を超える音も作成可能です。

Fugattoは、音楽制作、広告制作、言語学習ツール、ゲーム開発など、幅広い分野で活用できます。音楽プロデューサーは楽曲のプロトタイプ作成や編集に、広告代理店は多言語・多様な感情表現のボイスオーバー作成に活用できます。言語学習ツールでは、好きな声で学習コンテンツをパーソナライズすることも可能です。ゲーム開発者は、ゲーム内の状況に合わせて効果音をリアルタイムで生成・変更できます。

Fugattoは、音声モデリング、音声符号化、音声理解に関するNVIDIAの以前の研究成果を基盤としています。25億個のパラメータを使用し、NVIDIA DGXシステムとH100 Tensor Core GPUを用いてトレーニングされました。世界各国の研究者による多様な視点と協力体制が、Fugattoの多言語・多アクセント対応機能を強化しました。開発には1年以上の歳月を費やしており、テキストプロンプトからの音楽生成や、犬の鳴き声と電子音楽を組み合わせたサウンド生成など、開発チームを驚かせる成果が多数ありました。

Fugattoは、テキストによる自由度の高いサウンド操作を可能にし、音楽制作やサウンドデザインの可能性を大きく広げる革新的なツールと言えるでしょう。 新人のエンジニアの皆さんにとっても、AIによる音声生成技術の最先端を理解する上で、非常に有益な事例となるでしょう。

引用元: https://blogs.nvidia.com/blog/fugatto-gen-ai-sound-model/

このGitHubリポジトリは、vcraftjp氏によって公開されたMS-DOS用テキストエディタ「VZ Editor」のソースコードと関連ファイルを提供しています。 バージョン1.6が公開されており、PC-9800、J-3100、DOS/V、AX、PS/55、US版のマスターディスクイメージ、ソースコード(アセンブラ)、マニュアル(Markdown形式)、そしてエミュレータでの動作に必要なFDイメージが含まれています。 ただし、ソースコードをビルドするには、対応するフリーのアセンブラとリンカが必要となります。 また、マニュアルは一部内容を除いてMarkdown形式で提供されています。 多くのユーザーによって作成されたマクロは、現状では公開されていませんが、今後公開に向けて準備が進められています。 ライセンスはBSD-3-Clauseライセンスです。 PC-9801のエミュレーションにはNeko Project II x64、DOS/V版にはDOSVAXJ3が推奨されています。 本プロジェクトは、古き良きMS-DOS時代のテキストエディタを現代に蘇らせる試みであり、多くのユーザーから250のスターと5のフォークを獲得しています。

引用元: https://github.com/vcraftjp/VZEditor

福島県西郷村の小学3年生、石川禾奈子さん(8歳)が第2種電気工事士試験に合格し、話題になっています。 これは国家資格であり、電気工事の作業に従事するための専門知識と技能が求められます。禾奈子さんは筆記試験に加え、実際に工具を使って行われる技能試験にも合格したため、多くの注目を集めています。

特にネット上では、8歳という年齢で圧着ペンチなどの工具を扱えること、そして技能試験をクリアしたことに対する驚きと称賛の声が多く上がっています。 多くのユーザーが禾奈子さんの努力と才能に感銘を受け、その高い技能と、筆記試験合格のための学習努力に驚きの声をあげています。 中には、自身も電気工事士の資格取得を目指しているものの、学習の難しさに苦戦しているという声も見られました。

禾奈子さんの合格は、年齢に関わらず努力と才能があれば国家資格取得も可能であることを示す事例として、多くの反響を呼んでいます。 このニュースは、日本のエンジニア、特に新人エンジニアにとって、目標設定やモチベーション向上に繋がる可能性のある、非常に刺激的な出来事です。

引用元: https://togetter.com/li/2470890

（株式会社ずんだもんは架空の登場組織です）

本資料は、タイミー社がニアリアルタイムデータ基盤を構築した経験とその課題について報告しています。以前のデータ基盤はバッチ処理中心で、データの適時性と整合性に課題がありました。具体的には、数時間～1日の遅延と、データ更新による整合性の欠如が発生していました。

そこで、Google Cloud Datastreamを活用したニアリアルタイムデータ基盤を構築しました。embulkからDatastreamへの移行、dbtで生成するテーブルをviewに変更するなどのアーキテクチャ変更を行いました。その結果、データの適時性は数時間～1日から15分程度に、整合性のずれも数時間単位から最大4時間～1日に改善されました。

しかし、新たな課題も発生しました。Datastreamの不安定性が顕著になり、最大3時間以上の停止や、数分～1時間弱の頻繁な停止・復旧が発生するなど、運用上の課題が残っています。

これらの課題を踏まえ、社内ユースケースの整理を行いました。その結果、完全性が求められる業務の方が、適時性が求められる業務よりも多いことが判明しました。そのため、短期的な対応として完全性を担保できる基盤を構築し、適時性が必要なユースケースもサポートする方針となりました。長期的な対応としては、適時性データ基盤の連携方法を再検討していく予定です。

引用元: https://speakerdeck.com/chikushi/niariarutaimunodetaji-pan-wogou-zhu-sitede-raretamonotoke-ti

長年、実用化が困難だった5指駆動の筋電義手が、電気通信大学の研究者らによって「BITハンド」として実現しました。本記事は、開発を主導した東京理科大学助教の山野井佑介氏へのインタビューに基づき、その成功要因を解説しています。

従来の筋電義手研究は、人体の動きを完璧に再現することに注力していましたが、そのため義手が大型化・重量化し、実用性に欠けていました。山野井氏らの研究チームは、このアプローチを見直し、「日常生活に必要な把持動作の85％をカバーする」ことを目標に、軽量化と簡素化を優先しました。

具体的には、親指と他の指の独立した動作により、「握力把持」「精密把持」「側面把持」の3つの基本動作を実現。ペットボトルの開閉やスマートフォンの操作など、日常生活に必要な動作を可能にしました。重量は約600gに抑えられ、装着者の負担を軽減しています。

技術面では、機械学習を用いた信号処理技術が鍵となりました。微弱な筋電位信号から、着用者の意図を正確に読み取ることで、5本の指を独立して制御しています。特に、先天的な上肢欠損者にも対応できるよう、個々の筋電位パターンをAIが学習する仕組みを構築しました。

さらに、Bluetooth通信によるデータ送受信や、スマートフォンからの制御ソフトウェア開発など、実験効率の向上にも取り組んでいます。これらの工夫により、開発期間の短縮とコスト削減を実現しました。

しかし、実用化されたにも関わらず、国内での普及率は依然として低い状況です。高価で重いという従来のイメージが根強く残っていること、そしてその利便性が広く知られていないことが課題となっています。山野井氏らは、認知度向上とさらなる機能改善を目指し、研究開発を継続していくとしています。

引用元: https://levtech.jp/media/article/focus/detail_565/

JS.tfは、HCL(Hashicorp Configuration Language)を用いてJavaScriptプログラムを記述する、Terraformのプロバイダーです。terraform applyを実行することで、HCLで記述されたコードがJavaScriptにトランスパイルされ、Node.jsなどのJavaScriptランタイムで実行できます。

JS.tfの基本的な使い方は、required_providersブロックにkoki-develop/jsを追加し、terraform initでインストールすることから始まります。 プログラムの記述にはjs_programデータソースが中心となります。変数・定数の定義にはjs_var, js_const, js_let、演算にはjs_operation、関数定義にはjs_function、関数呼び出しにはjs_function_callといったデータソースを使用します。 js_for, js_while, js_ifなどの制御構文も用意されています。 詳細な使用方法や各データソースの機能については、公式ドキュメントとGitHubリポジトリのサンプルコードを参照ください。

JS.tfのメリットは、HCLによる記述により、プログラムの可読性が向上することです。 ただし、型安全性はJavaScriptと同等かそれ以下であり、コード量は多くなる傾向があります。 読みやすさを重視する開発スタイルや、チーム開発においては、そのメリットが活きてくるでしょう。 一方で、書きやすさや型安全性を重視する場合は、他のAltJSを選択する方が適切かもしれません。

引用元: https://zenn.dev/terraform_jp/articles/jstf-introduction

この投稿は、東大・東工大卒のエンジニア新人において、「口調が角張っていて不快」という指摘が非常に多いという内容です。投稿者は、論理的で正論に基づいた発言が、社会では必ずしも好まれないことを指摘しています。

特に、女性エンジニアに対しては「話し方を柔らかくする」というアドバイスがなされることが多いですが、これは女性差別的な側面を持つ可能性があると主張されています。男性であれば、より直接的な表現で指導される可能性が高く、女性特有の配慮が差別につながるという指摘です。

より効果的なフィードバックとしては、「発言が不快感を与え、クレームに繋がっている。改善できないなら、この会社では将来がない」といった、直接的かつ結果を示した上で改善を求める方法が提案されています。

多くのコメントでは、この意見に共感する声が上がっています。高学歴の理系出身者にとって、論理的な発言が自然で、それが社会では必ずしも良い結果に繋がらないという現実が浮き彫りになっています。 研究室や大学とは異なり、社会では感情に配慮したコミュニケーションが求められるという点が強調されています。

いくつか紹介されている書籍は、より効果的なコミュニケーションスキルを身につけるための参考として挙げられています。 新人エンジニアは、論理的思考力と同時に、相手に配慮したコミュニケーションスキルを磨く必要性を改めて認識する必要があるでしょう。 正論だけでなく、伝え方、つまりコミュニケーションスキルもエンジニアにとって重要な能力であることを示唆しています。

引用元: https://togetter.com/li/2470429

（株式会社ずんだもんは架空の登場組織です）

Gmailユーザーが、メール作成時にGemini AIによる回答候補が表示される機能に不満を訴えているGoogleヘルプフォーラムの投稿です。ユーザーは、この機能が邪魔で自分の考えでメールを書きたいと考えており、機能の無効化方法を質問しています。AIによる自動化が思考停止を招くという懸念も表明されています。 現状では、この機能を無効化する具体的な方法は提示されていません。 投稿は比較的新しいものですが、Googleからの回答はまだありません。 この投稿は、AIアシスタントの過剰な介入に対するユーザーの抵抗感を示す事例として参考になります。 日本のエンジニアにとって、この事例は、ユーザーエクスペリエンス(UX)設計や、AI技術導入におけるユーザーの感情への配慮の重要性を再認識させるものです。 AIによる自動化の利便性と、ユーザーの自主性や創造性を尊重することのバランスが、今後のシステム開発において課題となるでしょう。

引用元: https://support.google.com/mail/thread/309622575/gemini-ai-asst-suggesting-answers-to-my-emails-hell-no%3Fhl%3Den

AWS Step Functionsに、変数の使用とJSONataのサポートが追加されました。これにより、ステートマシンにおけるデータの受け渡し処理が大幅に簡素化されます。

以前は、Step Functionsでステート間の値の受け渡しは、各ステップで結果を明示的に次のステップに渡す必要があり、複雑で非効率的な作業でした。しかし、今回のアップデートで変数を定義し、ステート間で値を容易に共有できるようになりました。例えば、あるステップで計算した結果を変数に格納し、後続のステップでその変数を参照することで、データの受け渡しを簡略化できます。

具体的には、Pass、Task、Map、Parallel、Choice、Wait ステートで変数が利用可能です。変数はJSON形式で指定し、マネジメントコンソールで変数タブから設定できます。一度の変数割り当ての最大サイズは256 KiB、ステートマシン全体で保存される変数の合計サイズは10 MiBに制限されているため、注意が必要です。

また、変数のスコープにも注意が必要です。ParallelやMapステート内で定義した変数は、その内部でのみ参照可能です。上位のステップで定義された変数は下位のステップから参照できますが、下位ステップで定義された変数は上位ステップからは参照できません。ParallelやMapステート内で定義した変数を他のステップで使用したい場合は、明示的に出力として渡す必要があります。

さらに、JSONataというクエリ言語がサポートされました。これにより、ステートマシンの設定がより柔軟で直感的になります。JSONPathも引き続き利用可能です。

今回のアップデートにより、Step Functionsのワークフロー設計が大幅に簡略化され、より効率的で分かりやすいステートマシンの構築が可能になります。変数のサイズとスコープに注意しながら、積極的に活用することで開発効率の向上に繋げましょう。

引用元: https://dev.classmethod.jp/articles/step-functions-variables/

この記事は、TypeScriptとRustで記述された、VSCode拡張機能「sqlsurge」の紹介です。sqlsurgeは、PrismaやSQLxといったORMを使用せず、生SQLクエリを記述する際に、SQLの構文補完やエラーチェックといったLSP(Language Server Protocol)機能を提供します。

主な機能は、TypeScriptとRustのコード内にある生SQLクエリを検出し、VSCodeのVirtual Document機能とRequest Forwardingを用いて、Go製のSQL Language Serverである「sqls」と連携することで、SQLクエリに対する補完機能を実現する点です。 TypeScriptではPrisma、RustではSQLxをサポートしており、Prismaを使用している場合はSQLのシンタックスハイライトも有効になります。

sqlsurgeは、TypeScript/RustのAST(抽象構文木)を解析して生SQLクエリを特定します。Rustの部分はWASM(WebAssembly)に変換され、VSCode上で動作します。開発にはwasm-packを使用しており、CIにはGitHub Actionsを用いてUbuntuとmacOS上でのテストを実施しています。

現状ではPrismaとSQLxのサポートが中心ですが、将来的には他のライブラリや自作関数への対応、SQLクエリの実行機能、さらなるシンタックスハイライト機能の追加などが予定されています。 GoやPythonなど他の言語への対応も検討されています。

sqlsurgeを使用するには、VSCodeに拡張機能をインストールし、sqlsをインストールする必要があります。VSCodeの設定で文字列内の自動補完を有効にする必要もあります。

本拡張機能は、生SQLクエリを直接記述する開発者にとって、生産性を向上させる強力なツールとなるでしょう。

引用元: https://zenn.dev/senken/articles/vscode-sqlsurge

（株式会社ずんだもんは架空の登場組織です）

LLM（大規模言語モデル）は英語での能力が向上していますが、他の言語での性能はまだ未知数です。そこで、日本語のLLMの性能を評価する「Open Japanese LLM Leaderboard」が発表されました。これは、LLM-jpプロジェクトとHugging Faceのパートナーシップにより開発されたもので、20以上のデータセットから構成され、日本語LLMのメカニズムを理解することを目的としています。

日本語は、漢字、ひらがな、カタカナの3種類の文字を組み合わせた複雑な書き言葉体系を持ち、英語や中国語、オランダ語、ポルトガル語、フランス語、ドイツ語、アラビア語などからの外来語や、独特の絵文字や顔文字も存在します。さらに、日本語は単語間のスペースがなく、トークン化の難易度が高い言語です。

Open Japanese LLM Leaderboardは、日本語LLMの評価に特化したllm-jp-evalライブラリを使用し、16のタスクでLLMを評価します。これらのタスクには、自然言語推論、機械翻訳、要約、質問応答などの古典的なものから、コード生成、数学的推論、人間試験などの現代的なものまで含まれます。データセットは、LLM-jpの評価チームが言語学者、専門家、人間アノテーターと協力して作成したものや、日本語に自動翻訳され、日本語の特徴に合わせて調整されたものなどがあります。

このリーダーシップでは、Jamp、JEMHopQA、jcommonsenseqa、chABSA、mbpp-ja、mawps、JMMLU、XL-Sumなどのデータセットを使用しています。Jampは、NLIのための日本語の時間的推論ベンチマークであり、JEMHopQAは、内部推論を評価できる日本語の多段QAデータセットです。jcommonsenseqaは、常識的推論能力を評価する多肢選択式の質問回答データセットです。chABSAは、金融レポートの感情分析データセットで、2016年の日本の上場企業の財務報告書に基づいています。mbpp-jaは、Pythonの基本的な問題を日本語に翻訳したプログラミングデータセットです。mawpsは、数学的な問題を解く能力を評価するデータセットで、CoT推論を使用しています。JMMLUは、高校レベルのテストの知識を評価する4択の質問回答データセットです。XL-Sumは、BBCニュースの記事の日本語翻訳に基づく要約データセットです。

このリーダーシップは、Hugging FaceのOpen LLM Leaderboardに触発され、HuggingFaceのInference endpoints、llm-jp-evalライブラリ、vLLMエンジン、mdxコンピューティングプラットフォームを使用してモデルを評価します。

日本語LLMガイド「Awesome Japanese LLM」によると、MetaのLLamaアーキテクチャが多くの日本のAIラボで好まれているようです。しかし、MistralやQwenなどの他のアーキテクチャも、日本語LLMリーダーシップで高いスコアを獲得しています。オープンソースの日本語LLMは、クローズドソースのLLMとの性能差を縮めており、特にllm-jp-3-13b-instructはクローズドソースのモデルと同等の性能を示しています。

今後の方向性として、llm-jp-evalツールの開発に合わせて、リーダーシップも進化していく予定です。例えば、JHumanEvalやMMLUなどの新しいデータセットの追加、CoTプロンプトを使用した評価、NLIタスクでのアウト・オブ・チョイス率の測定などが挙げられます。

Open Japanese LLM Leaderboardは、LLM-jpコンソーシアムによって構築され、国立情報学研究所（NII）とmdxプログラムの支援を受けています。このプロジェクトには、東京大学の宮尾祐介教授、Han Namgi氏、Hugging Faceのクレモンティーヌ・フーリエ氏、林俊宏氏が参加しています。

引用元: https://huggingface.co/blog/leaderboard-japanese

（株式会社ずんだもんは架空の登場組織です）

食べログのメニューデータ入稿業務において、生成AIとOCRを組み合わせたツールを開発し、作業工数を6割削減することに成功しました。従来の手作業によるメニュー情報の入力は、時間と労力を要するものでした。本プロジェクトでは、まずOCR技術を用いてメニュー画像内の文字情報を座標情報と共に取得。その後、生成AIにOCR結果と画像データを渡し、料理名と価格を抽出し、入力フォームへ自動入力するシステムを構築しました。

生成AI単体では精度の問題がありましたが、OCRによる位置情報との連携により、生成AIの出力結果が画像上のどの部分に対応するかを特定できるようになり、精度の向上と確認作業の効率化を実現しました。ツールは、AIによる高速入力と、人による確認・修正作業を組み合わせた設計となっており、AIと人間の強みを活かす仕組みとなっています。 UIについても徹底的に作り込み、ハイライト機能、消し込み機能、入力支援機能などを搭載することで、確認・修正作業を大幅に効率化しました。

開発においては、常に最新技術の動向をウォッチし、GPT-4やClaude 3.5 Sonnetといった生成AIモデルの特性を踏まえた柔軟な方針転換が成功の鍵となりました。 特に、当初はOCRのみを利用する方針でしたが、GPT-4の登場を機に、画像データとOCR結果を組み合わせることで、精度と効率性が大幅に向上しました。また、完全自動化を目指さず、人による確認作業を残すことで、精度の高いデータ入力を実現しました。

本プロジェクトの成功要因は、生成AIだけでなくOCR技術など幅広い技術を組み合わせたこと、ユーザビリティを重視したUIの徹底的な作り込み、そして最新技術への対応と柔軟な方針転換にあります。 この経験から、生成AIの業務活用においては、フルスタックエンジニアのような幅広い技術を持つ人材が不可欠であることが示唆されました。 彼らは、生成AIの特性を理解した上で、様々な技術を駆使し、最適なソリューションを生み出すことができます。

引用元: https://tech-blog.tabelog.com/entry/ai-menu-ocr

LangChainは、様々なエージェントを連携させるマルチエージェントフレームワークLangGraphを発表しました。異なるフレームワークのエージェント間の相互運用性を高めるため、Agent Protocolという共通インターフェースをオープンソース化しました。これは、LLMエージェントを本番環境で運用するために必要な、フレームワークに依存しないAPIを標準化しようとする試みです。

Agent Protocolは、エージェント実行(Runs)、複数ターン実行の整理(Threads)、長期記憶の操作(Store)といった主要なAPIを定義しています。LangGraphだけでなく、AutoGen、OpenAI Assistant API、CrewAI、LlamaIndexなど、他のフレームワークや独自実装のエージェントもこのプロトコルを実装することで、相互運用が可能になります。

さらに、LangGraph Studioのローカル実行環境を提供することで、開発者の利便性を向上させました。以前はMac専用でDockerを使用していましたが、Pythonパッケージとしてインストール可能な、Docker不要のバージョンが提供されています。これは、langgraph-cli を使用してローカルで起動し、Agent Protocolを実装したサーバーとして機能します。これにより、あらゆるプラットフォームでLangGraph Studioを使用し、低レイテンシで効率的なデバッグが可能になります。

また、AutoGenなどの他のフレームワークのエージェントをLangGraphのサブエージェントとして統合する方法や、LangGraph Platformを使用してそれらをデプロイする方法も公開されました。LangGraph Platformを利用することで、水平スケーラブルなインフラストラクチャ、バースト処理のためのタスクキュー、短期記憶と長期記憶のための永続化レイヤーなどのメリットを活用できます。これにより、様々なフレームワークのエージェントを柔軟に組み合わせた、高度なマルチエージェントシステムの構築が可能になります。

本記事では、Agent Protocol の詳細な使用方法や、LangGraph Studio、AutoGenとの統合方法については触れていません。詳細は、記事中に記載されているリンク先を参照ください。

引用元: https://blog.langchain.dev/agent-protocol-interoperability-for-llm-agents/

この記事は、イオンが開発したレシートレス機能の開発背景と実装方法について解説しています。 日本の小売業界の巨人であるイオンが、レシートレス化という技術的にも運用面でも非常に複雑な課題にどのように取り組んだのか、その詳細を技術的な視点から紐解いています。

レシートレス化は、単にレシートを発行しないというだけでなく、顧客への情報伝達、会計処理、エラー処理、そして何よりも現実世界の複雑な店舗オペレーションとの整合性が大きな課題となります。 記事では、これらの課題を解決するために、イオンがどのような技術やシステムを導入し、どのような工夫を凝らしたのかが説明されていると考えられます。

具体的には、以下のような点が詳細に記述されていると推測されます。

記事全体を通して、大規模な小売企業におけるシステム開発の難しさ、そして現実世界の問題を解決するための技術的なアプローチが示されていると考えられます。 新人エンジニアにとって、大規模システム開発における課題や、現実世界の複雑さを考慮したシステム設計・開発の重要性を学ぶ上で貴重な事例となるでしょう。 ただし、記事本文にはアクセスできないため、上記は推測に基づいた要約となります。 詳細な技術的な内容や具体的な実装方法は、記事本文を参照する必要があります。

引用元: https://engineer-recuruiting.aeon.info/aeon-tech-hub/interview_receiptless

ヒストリカルコスチューム研究家の汐音凛氏（@shione_kageki）が、生成AIによる歴史コスチューム画像の精巧な偽造に警鐘を鳴らしています。以前はネット検索で正確なファッションプレートなどの画像が見つかったのに対し、現在はAI生成によるロココ風の画像が大量に表示され、真偽の判別が困難になっているとのことです。

同氏は、歴史研究においてネット検索が信頼できない状況になっていると指摘。AI生成画像は、リボン位置の不自然さ、現代的な顔立ち、時代考証に合わない装飾など、専門家であれば誤りと判断できる点が多いものの、専門知識を持たない者にとっては真偽の判断が難しいと懸念しています。

多くのユーザーも、AI生成画像の精巧さに驚き、容易に騙されてしまう可能性を指摘しています。例えば、古代ローマの衣装やロココ時代のドレスなどを検索した際に、歴史的正確性に欠けたAI生成画像が大量に表示されるという報告が多数上がっています。

この状況を受けて、汐音氏は紙資料や原典の重要性を改めて強調。ネットの情報は嘘と真実が入り混じった状態であり、正確な情報を取得するには、従来の紙媒体による調査が不可欠になっていると訴えています。 専門知識を持つ者でも見分けが難しいほど精巧なAI生成画像が出回っている現状は、歴史研究のみならず、デザイン等の分野においても大きな課題となっています。 日本のエンジニアの皆様も、情報収集においては、AI生成された情報の信憑性を慎重に確認する必要があることを認識しておくべきでしょう。 特に専門性の高い分野では、紙媒体の資料を参照することを強く推奨します。

引用元: https://togetter.com/li/2468174

（株式会社ずんだもんは架空の登場組織です）