1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「第3回 さくらのAIハッカソン with Kloud」に参加した

1
Last updated at Posted at 2026-08-29

「第3回 さくらのAIハッカソン with Kloud」に参加してきたので、参加レポートを書きます。

ハッカソンの概要

  • 開催期間: 8/18~8/26
  • 発表: 8/29 @ さくらインターネット株式会社 東京支社
  • テーマ: 「さくらのAIで『あったらいいな』を形にしよう!」
    • さくらインターネットが提供する「さくらのAI Engine」を活用する

(さくらのAI Engine: オープンモデルをAPIとして提供するサービス)

我々のチーム

開発期間

時系列

期間中、2人とも1週間ズレでインターンが入っていたため、非同期のコミュニケーションが中心でした。

Day(-2)~4: 課題の設定、具体化

前回のハッカソン参加時に直前まで課題が定まらなかったことの反省から、課題設定は早めに進め、具体化することに重きを置くことにしました。

課題、作るものの案としては、

  • 利用規約を作るのがめんどい 作るのを最適化
  • 期日から逆算して、一日の稼働量も考慮しつつ冗長生も担保してやること管理してくれるアプリ(緊急性は動的x)

が考えられました。この中で、評価観点が、

評価観点 配点
課題設定力 10
独創性/新規性 10
実装力 10
AI活用力 10
実用性 10

であることを考慮して、後者のスケジュール管理アプリでは

  • アプリケーションの難易度をある程度担保できる (実装力)
    • AIのアプリは非常に簡単だが、ハッカソンで求められているのがプロトタイプに近いことを考慮すると、実装力の点で差別化がしにくい
  • 理解と分類の部分で、AIのメリットを享受しやすい (AI活用力)
    • 利用規約アプリでは、AIの出力をかなりしっかりチェックする必要があるため、実用性を考えると、法務上のコストが大きい (AI活用力, 実用性)

と言った点で優位性を見出し、スケジュール管理アプリを作成することにしました。

使用技術

  • アプリケーション: Next.js
    • フロントとバックエンド(API Route)を一つで完結でき、MVP開発にあたってはコストが少ないため
  • DB: SQLite
    • 高度なSQLを書かないため
    • docker compose upのたびにDB起動に時間がかかると、開発ペースが落ちるため

を採用し、これらをDocker composeで運用しました。

Day5~6: 開発

開発では、主にKimi2.7-Code(AI Engineではpreview/Kimi-K2.7-Code)を活用しました。
課題の解決が特に難しいUIの一部などについてはCodexでGPT-5.6 Solを使用しています。

2026/08/27現在、クローズドモデルを除いて使えるモデルの一覧は次の通りです。

  • gpt-oss-120b
  • llm-jp-3.1-8x13b-instruct4
  • preview/Qwen3-0.6B-cpu
  • preview/Phi-4-mini-instruct-cpu
  • preview/Qwen3-VL-30B-A3B-Instruct
  • preview/Kimi-K2.6
  • preview/Qwen3.6-35B-A3B
  • preview/gemma-4-31B-it
  • preview/Kimi-K2.7-Code

(プレビューのモデルを使う際はpreview/をつけないといけないことがわからず少々苦労しました。OpenAI互換のAPIを提供しているので、/v1/modelsにリクエストを送ることでモデルの一覧が取得できます。)

Day7: スライド作成

ツール選択にあたっては、

  • AIからsuggestが受けやすいこと
  • 将来情報として活用する際、AIに食べさせやすいこと
  • ポインタの操作を減らせること
  • 再現性のあるスライド構築ができ、スライドの体裁(質)を担保できること

を考慮し、Marpで作成しました。私はこれを、SaC(Slide as Code)1と呼んでいます。

スライドの構成について

AIが市民権を獲得していくに従い、コーディングそのものの社会的価値は減少していくと考えており、プロダクト開発においては、より人間的で価値生産に直結する課題設定の重要性が増すと考えています。
したがって、課題設定を聴き手に私物化してもらえるよう、理解のための説明には相当の割合を割くこととし、以降の作るものや技術的詳細の説明においては、演繹的な流れの説明を主軸としながら、他チームにはない(だろうと思われる)特徴的なAI活用、あえてやらなかったことなどを小ネタ的に混ぜた構成としました。

作ったもの

GitHubで公開しています。

アプリ

Discord Bot

スライド

成果発表会

発表順に記載します。

1. 一杯いただきます 「飲んだ記憶を、記録に残す。」 (飲酒記録アプリ)

問題

  • お酒の名前や種類がわからない
  • ちゃんと記録しておかないと飲みすぎてしまう

解決策

  • 写真を撮ることで度数が自動で記録されるアプリ
  • 画像から候補を抽出するところ、翌日の振り返りにさくらのAI Engineを利用
  • お腹の空き具合による酔い具合に対する配慮→統計的にいつもより酔っているなどができる

記録をalertや振り返りみたいな形で活用できる点が、データを活用できていて良かった
Swift UIを使うとAI-drivenにやってもWebみたいに胡散臭くならないのがいいなーと思った

2. NO NAME 「Spectrum (スペクトル)」

  • レポート作成の補助
  • 品質を維持しながらレポート作成のコストを下げる
  • 主な機能
    • 論文などを検索
    • 採点
    • 形式の整形
  • Prismとの違い: Word, Google Docsへの対応
  • Chrome拡張機能

ずんだもん使ってるのが面白かった
最初の子のプレゼンがとても上手だった
Skillsにされているらしい 我々プロンプトエンジニアリングしかしてなかったので顔がないなと思った

3. DKブラザーズ 「ATODE」

  • 期限がなくても入力できるTODO
  • リマインドしてくれる
  • statusがdone/undone以外にもあってグラデーションを反映しやすい
  • stableなモデルで構成
  • 利用者の声も集めた
  • 5日間使ってもらったってことは3日でアイデアから開発までしてるのかな?
  • 実際LINEを使える形に持って行ってた

期限が明確でないけどなる早でやりたいことって結構あるので良さそうと思った
LINEっていうのがMVPらしくて良い
通知件数はユーザーが設定できると嬉しい
スコアリングのところはコアロジックになり、とても考慮されていたようなので、期間中のリソース配分としても上手だと思う

4. みやさんなのだ 「写真で相談! AIおたすけメイドちゃん」

  • ゴミ分別の種類が多く大変
  • 手書きのスライドは初めてみた
  • ゲームアプリのUIを参考に作成
  • 設定でボイス変更など、オプション周りで頑張った感じがする
  • 画面が映らないってなった時にPC画面を直接見せて対応するアジリティがすごい
    • (特に高2に当たる年齢でそれができている点)
  • 実際にペルソナにインタビューしている

Amamiyaさん前々回も見た気がする

5. くれてち 「Engoloyd」: 英単語学習の効率化

  • 丸暗記は忘れやすいので、接辞・語根学習/語呂合わせ
  • 観点が上に書いてる
  • これ実際のスライド中で実行までしてる...?
  • コストを考慮したEPの使い分けをしていた
  • URLが.github.ioだったけどインフラ構成はどうなっているんだろう
  • 「ディdifficultが難しい!」
  • 読み込み画面から、体系的に指示を誘導していることがわかる

最初に出てきた例がとても好き

6. 留数和 「どんな手を使っても絶対間に合わせるスケジューラ」

我々のチームです。感想ありましたらぜひお寄せください。

7. チェストつきさくらのボート 「Wake watch」

  • 導入がうまい
  • 目覚ましアプリ
  • Pixel watchをプラットフォームとした
  • 眠気度を評価
  • デモンストレーションで審査員を使っていた
  • watchを振って止まる
  • 起こし方、振り方、声をAIが考えてくれているらしい

8. あかさたな 「旅星」

  • 共有したい欲にフォーカス
  • 余白 の表現が上手い
  • whooに似てる
    • メモ+AIがある感じ
  • 行った場所はGPSから候補として、ユーザーのアクションにより確定する

PlantUMLを観測した
第一回で「あいうえお」っていうチームがいたけど関係があるんだろうか

9. Claude is all you need 「michi.」

  • どこで遊ぶかは場所が多いほど決めにくい
  • 要素を考慮して場所を提案する
  • 処理を分解してAIに渡していた
  • クロールもしてる
  • Kimi K2.7 Codeを使っていた
  • パフォーマンスチューニングに関する審査員の話はとてもその通りだと思った

nekoNAくん、前回もいたな
だいぶさくらのAI Engineに反旗を翻している感じのチーム名

10. 緯線 「Sakura 会話コンポーザー」

  • 文言の体裁修正をしてくれるツール
  • Gmailの"Describe your message"みたいな感じ?
  • 入力、AI支援、出力
  • 「Windows/MacOS/Linux対応」
  • 実際に使ってみていることがわかる質問への回答だった
    • コンテキストにパーソナリティを入れると自分(の模倣)に近づく

表彰

  • AI活用賞(さくらインターネット賞): Claude is all you need「michi.」
  • 優秀賞: DKブラザーズ「ATODE」
  • 最優秀賞: くれてち「Engoloyd」

発表で思ったこと

  • ほとんどのチームがスライド作成もAIにさせていたように見えた
  • AIによって課題解決の重みが増しており、時間に対するウェイトは多くのチームで多かった

開発で思ったこと

さくらのAI Engineとフロンティアモデルの使い分け

よく言われていることですが、性能の面で比較すると、オープンモデルでもQwen3.8-27Bのように強力なモデルは存在しているものの、Fable 5など強力なフロンティアモデルには劣ります。
さくらのAI Engineの強みは主として

  • コストの安さ
  • 出力の速さ

にあると考えており、計画や仕事の分担など、一般的に「人間がやるべき」とされている仕事から距離の近いタスクはフロンティアモデルに競争優位性が見られます。
一方、明確に定義された仕事を実際に進める、コーディングタスクなどの仕事ではコストの安いモデルでも完遂しやすく、オープンモデルのための計算機資源を提供するさくらのAI Engineの得意とするユースケースと言えます。

フロントエンドにおけるAI活用

フロントエンドにおけるAI活用には難しさを感じました。

例えば、UIを改善させたい際は、ほとんどのAIには目があるわけではないので、Playwrightによってログインフローをテストするなどはできても、非言語的なUXの部分には人間の介在が必要です。

成功したワークフローも紹介します。
ユーザーの動線を考える際、認知負荷や作業コストを下げることを主眼に置く場合、人間が

  1. 想定される動線を列挙させる
  2. より多くの動線で目的の達成しやすい動線を考えさせる

という手続きを手順づけてAIに実施させることで、漠然とした要求がタスクレベルに咀嚼され、アウトプットもより実体験を伴って改善が見えるものになりました。

  1. "Infrastructure as Code"のオマージュ

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?