関連リンク

• Geminiを使ったらKaggle初挑戦、参加期間10日間でも5位入賞できたので手法をすべて書く

この記事は、Kaggleコンペティション「LLM 20 Questions」に10日間だけ参加して5位入賞した著者が、その手法を詳細に解説したものです。著者は、MARCHレベルの物理系出身で、英語力・深層学習の知識共に専門家レベルではないと明言しています。Kaggle初心者や深層学習の基礎知識を持つエンジニアにとって、非常に参考になる内容です。

成功の鍵となったのは、Google Geminiの大規模言語モデルの活用です。API利用頻度と50万トークンものコンテキスト処理能力が必要だったため、Gemini以外では実現不可能だったと述べています。

著者は、Kaggleの情報を英語のまま処理するのではなく、コンペの概要、データ、ルール、ディスカッション、ノートブックをすべてGeminiで自動翻訳・要約し、マークダウン形式で整理するアプリケーションを開発しました。 このアプリケーションによって、英語の壁を乗り越え、Kaggleを日本語で完結に利用できる環境を構築しました。このアプリケーションはAWS Amplifyで公開されていますが、現在対応しているコンペティションは一つのみです。

コンペへの取り組みは、以下の3つのフェーズに分けられました。

1. 概要理解と環境構築フェーズ (2日間): コンペの概要を理解し、開発環境を整え、とりあえず提出を行う。


2. 情報収集と手法選定フェーズ (2日間): 主要なディスカッションとノートブックを分析し、最適な手法を選択する。


3. 手法改良と提出フェーズ (6日間): 選んだ手法を改良し、複数回提出を行う。

各フェーズにおいて、作成したアプリケーションで生成されたマークダウン形式の情報をGeminiのプロンプトに与え、対話的に質問することで、コンペの理解を深め、最適な手法の選定と改良を行いました。 Geminiとの対話を通して、コンペで勝利するための本質的な要素を理解し、手法の改善に繋げることができたと述べています。

著者は、この手法によってKaggle初心者でも上位入賞を目指せる可能性を示唆しており、特にコンペ終盤、ディスカッションやノートブックの情報が豊富になった段階で有効であると結論づけています。 ただし、この手法は活発なコミュニティ参加が前提となるため、注意が必要です。

引用元: https://qiita.com/yukky_memo/items/6e1c7fa08b9b91278886

• DeNA 流 SaaS の外形監視手法 BLOG - DeNA Engineering

DeNAのIT戦略部システム基盤グループは、社内向けに様々なSaaSを提供・運用しています。SaaSのメリットは導入コストや運用コストの低さ、セキュリティ対策のベンダー任せなどが挙げられますが、障害発生時の対応はベンダー任せとはいえ、従業員からの問い合わせ対応は運用担当者が行う必要があります。そのため、SaaSに対する適切な監視体制が不可欠です。

従来、各ベンダーが提供するステータスダッシュボードを利用していましたが、リアルタイム性や情報量の多さ、サービスごとのURL違いなど、課題がありました。そこで、Seleniumを用いた「外形監視」による監視手法を採用しました。

外形監視では、Seleniumを用いて、あたかも人間がSaaSを利用しているかのようにアクセスし、障害を検知します。AWSのEC2インスタンス上で、各SaaSごとにDockerコンテナを用意し、Seleniumを実行しています。コンテナはDocker Composeで管理し、cronとPythonスクリプトで定期的にSeleniumシナリオを実行します。

例えば、Slackの監視では、Botが定期的にメッセージを投稿し、そのタイムスタンプを監視することで、サービスの遅延を検知します。同様の手法で、Okta、Jira、Confluenceなども監視しています。シナリオは、各SaaSへのログイン、特定のページへのアクセス、データの取得など、実際のユーザー操作を模倣したものです。5分以上の遅延を障害と判定しています。

さらに、ベンダー提供のステータスダッシュボードを模倣した、社内向けサービスステータスダッシュボードを開発しました。このダッシュボードは、Seleniumによる外形監視の結果を集約し、各サービスの稼働状況を一元的に表示します。これにより、従業員はリアルタイムにサービス状況を確認でき、不要な問い合わせを削減できます。

今後は、SaaS以外のシステム（VPN、Active Directoryなど）の監視強化も予定しています。 このSeleniumを用いた外形監視システムは、SaaSの安定稼働と迅速な障害対応に大きく貢献しています。 新人エンジニアにとって、Docker、Selenium、Python、cronといった技術の理解が、このシステムの理解に役立ちます。

引用元: https://engineering.dena.com/blog/2024/10/saas-monitoring-tool/

• Go 1.24 から go.mod でのツール管理がより簡潔になるかもしれない

Go 1.24では、go.mod でのツール管理が簡素化される可能性があります。現状、Goで書かれたコマンドラインツールのバージョン管理は、tools.go ファイルを用いたblank importやMakefileを使ったgo installなどが一般的ですが、ツール追加・削除時の操作が複雑で、プラットフォーム依存性や既存ファイルのハンドリングなど、課題がありました。

Go 1.24では、この問題を解決するため、go.modにtoolディレクティブを追加する提案が採択されています。このディレクティブを用いることで、go getやgo mod editコマンドでツール依存関係を直接go.modに記述・管理できるようになります。 具体的には、go get -tool <パッケージパス>でツールを追加、go get -tool <パッケージパス>@noneで削除、go mod edit -droptool <パッケージパス>でも削除が可能になります。go tool <ツール名>コマンドで、go.modに指定されたツールのバージョンを確実に実行できます。このツールは$GOCACHEにキャッシュされるため、複数プロジェクトでの効率的なディスク利用も期待できます。

ただし、Go 1.24への正式実装は未定であり、リリースノートにも記載がないため、今後の情報に注意が必要です。詳細な情報は、関連するGitHub issueとDesign docを参照ください。 この変更により、Goツールのバージョン管理がよりシンプルで安全になり、開発効率の向上が期待されます。 新人エンジニアの方々も、Go 1.24リリース後にこの機能を活用することで、ツールのバージョン管理をスムーズに行えるようになるでしょう。

引用元: https://zenn.dev/uji/articles/adding-tool-dependencies-to-go-mod

• こんな見た目しているからさすがに模型だろうと思ったけど本当に段ボール製のドローン実機だった→使い捨て前提だから航続距離100kmで1kg以上積める

Togetterに掲載された記事によると、一見模型のように見えるが、実際は段ボールで製造されたドローン実機が存在するとのことです。このドローンは使い捨てを前提として設計されており、航続距離100km、積載量1kg以上という性能を備えています。

記事では、段ボール製であることから低コストで大量生産が可能であると指摘しつつ、その軍事利用の可能性についても言及しています。 軽量で安価な段ボール製ドローンは、大量投入による攻撃や災害時の迅速な物資輸送など、様々な用途が想定されます。一方で、その手軽さから、悪用されるリスクも懸念されています。

技術的な詳細や具体的な製造方法は記事からは読み取れませんが、使い捨て前提の設計により、コストと性能のバランスを取った革新的なドローン開発の事例として注目を集めているようです。 日本のエンジニアの皆様にとって、この事例は、材料選定やコスト削減、そして新たな用途開発における一つの参考事例となるでしょう。特に、軽量化、低コスト化、大量生産といった課題に取り組む開発において、この段ボールドローンの設計思想は非常に興味深い示唆を与えてくれます。 ただし、軍事転用や倫理的な問題についても考慮する必要があることを忘れてはなりません。

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

• お便り投稿フォーム

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