Posts on GITY Blog

地域創⽣・社会課題解決 AI プログラミングコンテストに参加してきました！

Mon, 22 Sep 2025 04:24:24 +0900

コンテストについて

この度私たちはAWSデジタル社会実現ツアー2025に参加してきました。このツアーは、地域社会の「DX」を加速し、持続可能な地域創生を実現することを目的としています。AWS主催の元、「産・官・学・金」がパネリストとして、参加し、ビジョンや、実績の共有、学生のプロダクトへのフィードバックなどを行いました。

私たち3人はこのツアー内で開催されたコンテストにプレゼンテーターとして参加し、多くのことを学んできました。各々の学びと成果を皆さんにもお伝えできれば幸いです。

初めに

昨今、巷では地域創生が求められており、国や地方自治体はDX推進や技術発展のための「場」を作ることに注力しています。例えば経済産業省からは未踏やGENIAC、AKATSUKIプロジェクトといった事業が行われており、コミュニティの形成や人材育成が行われています。

地方自治体や地場企業も同様にコミュニティの形成やコンテストの開催等の積極的な活動が行われている他、金融機関によるベンチャーキャピタルの立ち上げなど、地域の若手人材や起業家の育成も行われています。

それらの活動が実を結び、実際に様々なコミュニティが形成され情報共有やリソースの循環を通して熱意ある人々が様々なイノベーションを起こそうとしています。

知見の広がりと学び

日本各地の取り組み

日本各地で、様々なコミュニティが創生されていることを知りました。例えば新潟では学生が主体となって社会課題解決のためのイベントや活動を行う「NINNO3（ニーノスリー）」の紹介がありました。北九州の「COMPASS小倉」は市内総生産4兆円をビジョンに掲げ、創業交流会やイベントを通じて地域への思いを持った起業家を支援し、人々をつなぐ場となっています。

経済力のある地域では地方とはまた異なった様子を見ることができました。大阪市のQUINTBRIDGEでは企業パートナーと共に「学ぶ」「つながる」「共創する」を掲げ、人々の交流と挑戦の場となっています。年間700以上のイベントが行われ、日々交流しています。QUINTBRIDGEには活気ある人々が集まり、“共創プロジェクト"を通して課題解決を試みる挑戦的な場所でした。

これらの場所のすべてに共通するのはGITYと非常に似た特徴を持っているということです。学びを通して成長していくコミュニティを形成する機能を持った場所であることです。人と人がつながることで新たな交流が生まれ、宝石の原石であるユニークなアイデアは交流を通して磨かれます。

日本各地でこういった場所が誕生しているということへ驚きと機会提供のありがたさを実感しました。

政府による事業も知ることができました。経済産業省はGENIACというAI開発・発展のためのコミュニティの形成を試みています。AI開発者や企業の情報交換やフィードバックが行われています。学生向けのオンラインコミュニティ形成の構想もあり、AI開発コミュニティの裾野をより若い世代へと広げたいとのことでした。

AKATUKIプロジェクトでは、地方でのトップIT人材、企業家の人材発掘を進めるために、プロジェクトを遂行するための環境と、能力のある若手人材への投資をしてくれる環境がありました。北九州では、AKATUKIプロジェクトに採択されている学生がいて、AIの力を活用し、地域文化への理解促進と、持続可能な観光体験を創出するための観光アプリを発表しました。技術力の高さと、着眼点に驚きました。

/ AWSでは、スタートアップ支援を行っており、AWS japanの本社内には、AWS Startup Loftを設置していました。新しいものを生み出そうとする人々が集まり、刺激し合い、新たなものが生まれる場所でした。概要と利用方法は、こちらです。

参加してみての学び

次に今回のコンテスト最大の学びは、「熱意と責任感をもって挑戦することが大切」だということです。

良いものを作るには、熱意と責任感が大切だと感じました。これらがあれば、困難な壁を越えたり、モチベーションを維持して継続したり、最後の踏ん張りがきくようになると感じました。もしこれらが欠けていると、中途半端なものしか作ることができず、良いものは作れないと思いました。

また、自分は臆病な性格なので、少しハードルが高くても、飛び込む勇気も必要だと気づかされました。

コンテスト内での優勝者は皆、熱意をもって作ったプロダクトとプレゼンで、優勝していました。そして、自分のプロダクトに愛着と誇りを持っているひとたちだと感じます。

小林大起

発表を通じて見えた外に出す価値

私たちの作品は、新潟大会で最優秀賞を受けたことをきっかけに、「基準作品」として各地で紹介されるようになりました。これまで6会場では技術担当として裏方に回り、質問対応を担ってきましたが、AWSの滝沢さんに「せっかくだからチャレンジしてみない？」と声をかけてもらい、北九州大会では初めて発表者として登壇することに。

実際にステージに立つと、必要以上に緊張し、人前に出ると極端に硬くなる性格がそのまま出てしまいました。プレゼンの最中はカンペから目を離せず、言葉も思うように出てこない。正直、心の中では「失敗だ」とつぶやいていました。

ところが終わってみると、審査員や参加者からは「熱量がすごく伝わった」との声。自分では全くうまくいかなかったと思っていたのに、外からの印象はまるで違っていたのです。このギャップこそが大きな発見でした。

さらに、技術的な質問に加えて「このプロダクトをぜひ使いたい」という声や、導入の相談まで寄せられました。単なる説明の場ではなく、プロダクトが“次の現場”とつながる出会いの場になっていたのだと気づかされました。

今回の経験で強く感じたのは、プロダクトは公に出してこそ真価を発揮するということ。完璧な発表でなくても、外に出すことで思わぬフィードバックや新しい縁が生まれること。緊張で言葉が詰まっても、それでも伝わるものがあるということです。

これからも発表や公開の機会を積極的に持ち、外からの声を取り入れながらプロダクトを磨き上げていきたい。外に出す勇気が、次の成長を引き寄せてくれると確信しています。

山田陽仁

AWSコンテストを通して気づいた「伝える力」

今回、コンテストに参加して強く実感したのは「どれだけ良い内容でも、伝え方次第で人の受け取り方は大きく変わる」ということでした。
私はまだまだ拙く、プレゼンに自信があるわけではありません。ですが、新潟・名古屋・大阪・東京・仙台の5回のプレゼンを重ねる中でいただいた温かいフィードバックを通じて、「伝えること」の意味を少しずつ掴んでいけた気がします。

最初のプレゼンで感じたこと

最初のプレゼンで学んだのは、ただ事実を説明するだけではなく「ストーリー」があることで相手の心に届く、ということです。なぜその取り組みをしたのか、どんな思いを込めたのか。その背景を語ることで、内容以上に想いが伝わるのだと実感しました。

フィードバックに支えられて

その後のプレゼンでは、ありがたいことに「自信を持って話せているのが良い」と言っていただけたり、回を重ねるごとに一緒に回ってくださった運営の方から「すごく上達した」と声をかけてもらえました。
そうした言葉は大きな励みになり、「まだまだ」な私でも、少しずつ前に進めているのだと実感できました。

（AWSの方に「緊張は誰でもするので、優しそうな人を一人見つけて、その人を見て話して、その人が頷いたら次は違う人を見るというのを繰り返すと、緊張が多少は解れますよ😊」とアドバイスをいただいて、とても安心しました笑）

5回を通じての気づき

5回のプレゼンを通じて分かったのは、プレゼンは「完璧に説明する場」ではなく「想いを届ける場」だということです。

ストーリーが人を動かし、
言葉が理解を助け、
熱量が共感を生む。

私はまだ道半ばですが、この経験を通して「伝えること」そのものが、プロダクト開発と同じくらい大事な力だと気づきました。これからもいただいたフィードバックを大切にしながら、少しずつ成長していきたいと思います。

真庭詩音

おわりに

今回の発表でいろいろとご尽力いただいた皆様、誠にありがとうございます。多くの学びと、経験をすることができ、ものすごく勉強になりました。 GITYの皆様、今後ともよろしくお願いいたします。

来たるべきAI地方幕府時代に向けて畑を耕す

Wed, 18 Jun 2025 16:09:20 +0900

これはなに

いま、クーデターがアツい。¹ある技術書²によれば、統制の取れた実力組織と専門職、特に電気・情報系を用意し、電撃的に国家中枢とメディア設備を奪取すればよいらしい。コトが終わったら国家運営を実質的に担う官僚組織を懐柔することも忘れずに。ところで、GITYには専門職の豊富なリソースが揃っている。発達したAI技術は硬直した官僚機構よりも素晴らしい働きをするだろう。これは巨額の投資を受けるAIベンチャー企業のCEOたちの発言を引用するまでもなく明らかなことだ。³あとは実力だけ。

はじめに

今、日本の食料安全保障は危機に瀕している。農家の平均年齢はおおよそ68歳であり⁴、定年退職をきっかけにして就農した高齢者ですら、農家コミュニティの中では”ワカモン”として扱われる現状がある。従来的な農家の経営体には当然限界が来ており、農家の戸数は減少を続けている⁵。とうちゃんが死んじまったから、もう体力が/腰が限界だから、トラクターが壊れたから、太陽が眩しかったから、離農した。
直近に起こったイベントに目を向けよう。ロシアのウクライナ侵攻以降、肥料価格は過去に例を見ないほど高騰した。農家はさらなる適正施肥を求められ、一層効率的な経営を求められている。⁶南海トラフ巨大地震の予測以降、米価の高止まりが続く。令和の米騒動とまで名前が付き、一躍巨大政局にまでなった。⁷
このような現状に対し、地方から食料安全保障の一翼を担おうという動きが生まれるのは当然だろう。とにかくカロリーベースだ！育てるのはイモ類！チャラチャラしたルッコラとかアイスプラントとか、そういうよくわからん草は育てん！

準備

まずは土と苗を用意する。これは材料と設計図にあたる。土は植え付けのしばらく前までに施肥を行い、よく耕す。団粒構造を形成することが望ましいが、必須ではない。苗は種苗店に事前に注文しておく。必要なぶんだけを購入すること。苗は自然の中に普遍的に存在するから不要である⁸、という都合のいい話はない。
サツマイモの苗は茎の形で販売される。成長点が無事ならばとりあえずよいので、葉がしおれていても問題はない。買ってすぐ植え付けないならば、ビニール袋を掛けて蒸散を抑制し冷暗所に仮置きするのが良いだろう。

畝の作成や植え付け時には特に理性が必要というわけでもない⁹ので、徹夜でぼけた頭でも十分作業可能だが、熱中症には十分注意するように。電解質と水分を準備しよう。どれだけ扱いにくいワーカーであっても、この炭素生命体を使うしかない……

畝の作成/マルチング/植え付け

畝を作成し、マルチで覆い、苗の植え付けを行う。この作業に熟練することによって、貴方がたは来たるべきAI地方幕府時代において然るべき地位を占めることができる。WIRED読者¹⁰がわかりやすいように言い換えよう。大半の労働者が失業する時代ーーホワイトカラーがAIエージェントに、ブルーカラーがヒューマノイドロボットに置き換えられ¹¹、あらゆる機械がアデノシン三リン酸ではなくエレクトロンによって駆動するニューラルネットワークによって制御されるようになった時代¹²においても、おまんまの食い上げにはならない、ということだ。
具体的に考えていこう。高精度な位置情報サービスが広く提供され、自動運転技術も飛躍的に飛躍した現代において、重機を自動運転して省力化を図ることはごく自然な論理の帰結である。実際にダムの建設現場などにおいてすでに実用化されており¹³、当然農業分野においても実証実験が進んでいる。貴方の畑が十分に広ければ導入できるだろう。トラクターで外周を1周ぶんを人力で運転しなくてはならない¹⁴としても、労力を削減できるくらいに広い畑を持っているならば、だが。コストをペイできるかは更に別の問題だ。¹⁵

汎用人型ロボットに畑を耕させる？何を言っているのかをまず理解しよう。これは不均一なソフトマテリアルの上を二足歩行する可動部の塊に防水防塵機能をつけて重量物を振り回させたいという要求だが、無理だ。デジタルツイン内で加速/並列してAIに制御を学習させるとか、もはやそういう次元の話ではない。無理なもんは無理にゃ！農作業の具体的なやり方についてはここでは取り扱わない。YouTubeでも見とけ！¹⁶実際のところ、この手の作業はマニュアル化するには細かすぎる経験知が大量に必要なので見て覚えるのが一番早い。テキストですべてを説明してほしいオタクくんには難しいわけである。あなたを土に植えるわ。生まれ変わりなさい。¹⁷土を掘り上げて畝を作成する際に、高畝だからといって深く掘る必要はない。群馬県の大半の畑では改質されている層の下に固く締まった黒ボク土がある。¹⁸改質された層がない？それは可哀想に……リン酸を主体に施肥を行うのが良いだろう。

終わりに

未曾有の少子化を背景に、人手不足が声高に叫ばれる昨今。地方自治体も当然その影響を受け、特に土木職の充足率は驚くほど低い¹⁹。民間セクタに目を向けても同様、土木の現場を担う人材の確保は年々難しくなっている。²⁰世界的なインフレや通貨変動、自由貿易の後退などにより、施工費は前例のないレベルに高騰している。²¹これらの要因が合わさり、地方のインフラを維持することは難しくなりつつある。ひとたび臨界点に達すれば、放棄される地域も出てくるだろう……現段階の世論を参照しても、現実的な選択肢として受け入れられ、大きな反発もないことが予期できる²²。スマートシティ構想は糖衣（ドラジェ）にすぎない。

つまり：地方に中央政府の支配が及ばなくなる。あるいは、介入が遅れる。ここに我々の勝機がある。インドア派のもやしっ子ばかりだが、エレベーターでなく階段を使う体力はある。²³みな気のいい奴らばかりだ。牛乳も飲んでいる。²⁴当然、年寄り連中に遅れを取るつもりはない。もはや事態は取り返しの付かないところまで来ているのだ。我々が、自らの手で地方を創生する。君たちにも畑を耕してもらうことになるだろう。

告知

GITY農業はシリーズものです。次回作をお楽しみに！

諸説ある。 https://jp.reuters.com/world/korea/TUWACF5E25K7TKFPRB4DGEV5MA-2025-04-14/ ↩︎
技術書にしては珍しく、中公新書から出ている。 ↩︎
イーロン・マスクの米政府効率化省による取り組みとその結果を見れば明らかだろう。 ↩︎
農林水産省農業労働力に関する統計 ↩︎
農林水産省経営体に関する統計 ↩︎
土壌分析と有機物で肥料コストを抑えよう！適正施肥のススメ ↩︎
ニッセイ基礎研究所　令和の米騒動が起きた背景と農業の現状－米の価格高騰はなぜ起きた? ↩︎
seminarium ↩︎
今回は種子ではなく苗を使用するためだ。(ationes seminales) ↩︎
君たちのことだ。 ↩︎
三菱総合研究所ヒューマノイドロボットへの期待：社会実装される5つの意義 ↩︎
ここに大変わかりやすい動画がある。 ↩︎
数年前から様々な工程が自動化されて現場に導入されている成瀬ダムで自動化施工システムによる「現場の工場化」を実現ダムコンクリート自動打設システム ↩︎
コンバインなら外周3ぶんは手動運転になる。一部に手動運転が必要であることはカタログの隅っこの小さい文字とか規制省庁のガイドとかに書いてある。最新機種は若干マシになったらしい。 ↩︎
三菱総合研究所日本のスマート農業はなぜ普及が進まないのか？ ↩︎
このような動画が有限可算個存在する。無限と言うとグーで殴られる本当にひどい環境にいます。 ↩︎
私は神農信仰が好きだ。 ↩︎
農研機構が日本土壌インベントリーという本当に素晴らしいサービスをリリースしている。 ↩︎
2021年時点の分析でこれであり、例えば中国地方の自治体はすべて確保に困難を抱えている。国家公務員ですら採用予定人数を確保できていない。 ↩︎
リコー土木業界の人手不足を解決する方法と成功事例｜生産性向上のカギとなるポイントも紹介しかし、“アニキ"について現場に行くだけで年収600万いった時代のそれを維持できる訳がないだろう。 ↩︎
みずほリサーチ&テクノロジーズ　建設分野における物価等動向について　今は更に高騰している。 ↩︎
これを見てほしい。国民の皆様の素晴らしい意見が拝聴できる。 ↩︎
GITYはGSレジデンスの二階に位置しているが、エレベーターは止まらない。 ↩︎
本当は「毎日豆乳も飲んでいる」としたかったが、最近GITYに宅配牛乳が導入されたため改稿された。話は変わるが牛乳（やコーラ）を飲むのか、それとも植物由来の代替ミルクを飲むのかによって深刻な対立を起こしている国もあるらしい。その国の首脳は白い家に住んでいることで知られている。 ↩︎

駄菓子屋ひびのば&次世代の塾Sociusで働く私のおしごと

Tue, 03 Jun 2025 13:00:36 +0900

初めまして

今年2月から株式会社CATENASで働いています。いでまです。よろしくお願いします！ GITYで過ごす毎日が楽しくて仕方ないです＾＾

簡単に自己紹介

名前：いでま
年齢：24歳
趣味：イベント企画
特技：手話／打楽器／音速飯店（ボードゲーム）
座右の銘：死ぬこと以外かすり傷
マイブーム：働き方を模索しながら働くこと

なんの仕事してるの？

GITYでの教育事業「Socius（ソキウス）」の運営、駄菓子屋「ひびのば」の運営・インフルエンサーをしています。誰もが主体的に学び続けることができる社会をつくるために、さまざまな角度から活動を広げていくこの仕事が楽しいです！

Sociusのミッション

Sociusはいわゆる学習塾とフリースクールを運営しています。「いわゆる」と付けたのは、この「塾」「フリースクール」というラベリングがイメージを操作してしまっているんじゃないかと考えたからです。

Sociusのミッションは"出会い、繋がり、誰もが”共育”の主人公。“

学校に「行かない」という選択が、ネガティブな不登校のイメージではなく、シンプルな、新たな選択肢として捉えることが当たり前になるような社会を作りたいと思っています。

学習塾も同じで、従来の知識詰め込み型の塾ではなく、勉強に向かうモチベーションを高めることを目的とした、生徒と大学生講師間での”学び合い”を重視しています。

駄菓子屋ひびのばってなに？

大学生と一緒に運営している駄菓子屋さんです！今年の4月25日にオープンしました！

営業日：毎週火曜日・金曜日
時間：15:00-18:00
場所：群馬県前橋市南町３丁目74−１１まだ営業日が少ないのですが、徐々に増やしていけたらと思っています！また、店舗数も増やして、いろんな地域の方へ駄菓子屋で生まれるコミュニティを楽しんでもらえるようにしたいなと思っています！

SNSも頑張ってます

ひびのばはInstagramで発信をしています！このアカウントも、県内の大学生たちと一緒に作っています！SNSマーケティングを学生同士で学び合える場として、日々奮闘中です！一見、SNSの世界はキラキラしているように見えますが、緻密に分析と改善を重ねている学生たちの姿は本当にたくましく、リスペクトが止まりません！ SNS班の子達が作ってくれた台本の言葉ひとつひとつの意味や意図を読み解きながら、一生懸命頑張っているのでぜひチェックしてみてください！お店にも遊びに来てくださいね〜！

仕事の中で大事にしていること

自己決定の機会をなるべく多く作る

学校に通わないという選択をとった子たちは、社会の中で学んでいくということであり、一つ一つの意思決定がその後の人生に大きな影響を与えることがあります。日々の小さな決断も、学校に行く・行かないという大きな決断も、子どもが「自分で決めたのだから頑張ろう」と思えるような環境づくりを重視していきたいと思っています。

駄菓子屋の運営でも、Sociusの学生と関わるときでも、大事にしていることは共通しています。学生の主体性を尊重し、やりたいこと・学びたい学習が実現できる場所にしてほしいという思いのもと、活動しています！

どこまで自分の意見を伝え、どこからどうやって学生に任せるのか。

真のリーダーシップとか、コミュ力とか、いろんなテーマで対話を繰り返し、学びでお腹いっぱいになるような、そんな毎日です…！

終わりに

GITYを運営する株式会社CATENASでの生活について、考えていることなどざっくばらんに書かせていただきました。いかがでしたか〜！

GITYは今日も、平和です。どれくらい平和かというと、学生が甘食を分け合いっこしてくれたり、その横で急須でお茶を入れてくれたり、それくらい平和です。あと社会人の方がかわいい駄菓子をちょこちょこ買って交流してくれるのも、嬉しいです、萌えます！＾＾

GITYに来てから約４ヶ月。穏やかさと新しさ、面白さを兼ね揃えたすげえ居場所だなと思います！これからも、楽しみながら学びを積み重ねて成長していけるよう頑張ります！

最後まで読んでいただきありがとうございました！

お前のバックエンドサーバーは20行でMCP Serverになる

Sat, 03 May 2025 02:26:19 +0900

世間の技術の話題といえばLLMでもちきりになってしまいました。QiitaやZennのトレンドはMCP ServerやLLMの話題で溢れかえっています。

私はそんなAIに溢れかえっている今の風潮があまり好きではないのですが、全身逆張りオタクのような¹言動ばかりしていては世間に取り残されるのみです。

そんなわけで私もこの流行に便乗し、LLMくんのコミュニケーションツールであるMCP Serverを実装していきます。

事前知識のおさらい

MCPとは? LLMのTypeCと呼ばれる謎の物

まず、「MCPとはなんぞや？」という疑問に答えましょう。

MCP（Model Context Protocol）は、LLMと外部のサービス/アプリケーション間で安定的かつ効率的に通信するために設計された通信プロトコルです。アプリケーション層のプロトコルであり、平たく言えば特定のJSONを返すREST APIサーバーです。

簡単に言えば「LLMと喋るためのUSB Type-Cケーブル」のような役割を果たします。

従来、LLMと外部サービスを繋げようとすると、OpenAI APIのような独自仕様のREST APIやWebSocket、果てはRPCのラッパーなど、実装者ごとにバラバラな通信方法が使われてきました。

MCPはこれを標準化し、「モデルとクライアント及び情報源の間でやり取りするメッセージの形式・流れ・エラー処理」を統一することで、LLMが外部サービスへアクセスしやすくなり、ハルシネーションを減らしたり作業を代行したりできます。

MCP Serverとは

MCP Serverとは、このMCPプロトコルを話せるサーバー側の実装を指します。具体的には、

LLMから要求された情報を提供する
LLMに従って副作用を伴う特定の処理を行う

といった機能を備えたサーバーのことです。

MCPが実装された任意のアプリケーションと任意のモデルが通信できることにより、サービスを自由に接続できるようになります。IFTTTのLLM版というのがわかりやすい表現でしょうか。

とはいえ、MCPの仕様はそこそこ複雑です。

「じゃあ俺が今からMCP Serverの全プロトコル実装を書くぞ！」というのは、なかなか骨が折れます。

ckanthony/gin-mcpはすごいぞ

MCP Serverが何をするものかというのがわかったところで早速作っていくわけですが、一からこのプロトコルを実装するのはちょっと面倒です。

以下のようなGolang用のライブラリが公開されてはいますが、これらを利用して構築しただけでは世間にあふれかえる記事と全く同じつまらないものになってしまいます。

私のような怠惰な人間はLLMによる効率化のための手間すら面倒なのです。

そんな私にうってつけのライブラリがこちら。ckanthony/gin-mcpです。

このライブラリは名前の通り、みんな大好きGinフレームワークと組み合わせて「超お手軽にMCP Serverを立てられる」ことを目的に作られています。

MCPの中には情報を取得・操作するインターフェースを提供するToolと呼ばれるものがあります。LLMが実際に使えるTool(道具)というわけです。gin-mcpはGinで構築されたToolを一瞬で作成できます。

GITYで開発されている実際のプロジェクトに導入してみた

元になるコード

以前にこのブログで、Seedsnの技術スタックを紹介しました。今回はSeedsnにGinを導入していきます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


config, err := conf.Get() // 設定を取得
if err != nil {
 return err
}

// Initialize the Gin engine.
slog.Info("Initializing the Gin engine")
engine := gin.Default()
setRoute(&engine) // 別の関数でルーティングを設定


// Run the server.
slog.Info("Starting the server")
if err := engine.Run(config.ServerPort); err != nil {
 return err
}

SeedsnのAPIサーバーの起動処理を行っている部分です。直接的な関与のない一部の処理を省略しています。

今回はこれに手を加えていきます。

追加するコード

適当な場所で以下のような関数を定義しましょう。やることはこれだけです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import (
 "github.com/catenas-g/seedsn/conf"
 mcpserver "github.com/ckanthony/gin-mcp"
 "github.com/gin-gonic/gin"
)

func setMCP(e *gin.Engine) {
 s:= mcpserver.New(e, &mcpserver.Config{
 Name: "Seedsn MCP Server",
 Description: "Seedsn MCP Server",
 BaseURL: "https://localhost:8080/",
 })

 s.Mount("/mcp")
}

設定の値はそれぞれ書き換えてください。ckanthony/gin-mcpはgin.Engineに対していろいろ加工をしてあげることでMCP Server化します。

関数を作成したら、これを実際に呼び出します。

 1config, err := conf.Get() // 設定を取得
 2if err != nil {
 3 return err
 4}
 5
 6// Initialize the Gin engine.
 7slog.Info("Initializing the Gin engine")
 8engine := gin.Default()
 9setRoute(&engine) // 別の関数でルーティングを設定
10
11setMCP(engine) // Call to set up the MCP server
12
13// Run the server.
14slog.Info("Starting the server")
15if err := engine.Run(config.ServerPort); err != nil {
16 return err
17}

ルーティングの設定直後にsetMCPを呼んであげるだけです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


INFO[0000] Starting conversion of 2 routes to MCP tools...
INFO[0000] Processing route: GET /api/v1/projects -> OpID: GET_api_v1_projects
INFO[0000] Processing route: GET /api/v1/projects/:id -> OpID: GET_api_v1_projects_id
INFO[0000] Finished route conversion. Generated 2 tools.
INFO[0000] [SSE] Creating new transport at /mcp
INFO[0000] [Transport DEBUG] Registered handler for method: initialize
INFO[0000] [Transport DEBUG] Registered handler for method: tools/list
INFO[0000] [Transport DEBUG] Registered handler for method: tools/call
INFO[0000] [Server Mount DEBUG] Defining GET /mcp route
[GIN-debug] GET /mcp --> github.com/ckanthony/gin-mcp.(*GinMCP).handleMCPConnection-fm (7 handlers)
INFO[0000] [Server Mount DEBUG] Defining POST /mcp route
[GIN-debug] POST /mcp --> github.com/ckanthony/gin-mcp.(*GinMCP).Mount.func2 (7 handlers)
03:36:46.997 INFO Starting the server
[GIN-debug] Listening and serving HTTP on :8080
hayao@Hayao-XPS9350 ~/G/s/api (Hayao0819/mcp-server) [1]>

サーバー起動時に見慣れないログが出力されれば。MCPサーバの構築は完了です。

Clineから呼び出してみた

ClineにMCP Serverを登録する

テストとしてClineから呼び出してみましょう。今回は呼び出しのモデルにgemini-2.0-flash-001を利用しています。

以下のようにMCP Server登録します。

1
2
3
4
5
6
7
8
9


{
 "mcpServers": {
 "Seedsn": {
 "url": "http://localhost:8080/mcp",
 "disabled": false,
 "autoApprove": []
 }
 }
}

実際に呼び出してみる

次のようなプロンプトでSeedsnのAPIを使うように指示します。

1

私は群馬に住んでいるパソコンが好きなオタクです。Seedsnに登録されているプロジェクトのうち、私におすすめのものを教えてください。

どうやらちゃんとMCP Serverを使ってくれそうです。

APIの返答が色々と表示された後……

無事にちゃんと情報を取得して返してくれました。

終わり

僅か20行程度でMCP Serverと進化させることができました。エンドポイントやハンドラは一切触れず、gin.Engineに細工をしただけです。

残念ながら認証についての実装を行っていないのでプロジェクトの追加や削除といったことは行えませんが、それでもこの手軽さには驚きです。²

もう少ししっかりと設定をしたうえで、Seedsnのプロジェクトを誰でもLLMで活用できるようにMCP Serverの実装を進めていけたらと思います。

皆さんもGinを使ったプロジェクトがあったらぜひ導入してみてください。それでは、また今度。

比喩表現であり私自身はｹｯｼﾃ ↩︎
驚き屋さんになったのは初めてなのですが、うまくできていますか？ ↩︎

東方Projectの音楽をSC-88ST Proで聴ける環境を構築した話

Sun, 23 Mar 2025 20:51:12 +0900

こんにちは、山田ハヤオです。

皆さんは東方projectというものをご存知でしょうか？

1996年から続く弾幕シューティングゲームのシリーズのことなのですが、私はそのゲームの音楽が大好きです。

ということで今回は、GITYでこのゲームの音楽を聞いていきます。

MIDIとは

音楽をやっている方はご存知だと思いますが、昔から存在する音楽形式にMIDIというものがあります。

mp3やwav等の音楽形式は「音声データそのもの」を持っていますが、MIDIは「演奏する方法」を持っているデータ形式です。

MIDIは「どこの鍵盤を何秒押すのか」という情報しか持っていないため、それを鳴らすための音源が必要になります。

SC-88STPro

現代ではMIDIの音源にはソフトウェアを使うことが大半ですが、かつてはハードウェアMIDI音源という、MIDIを鳴らすための専用の器械がありました。

東方Projectの初期の頃のゲームもこのハードウェア音源が無いと当時の音を再生することができません。

ということでヤフオクで入手したのがこちらですドン！

入手してしまいました。SC-88ST Proです。

東方Project作品の推奨音源はSC-88Proです。SC-88ST ProはSC-88Proと音源として完全な互換性があります。違いは液晶の有無で、所謂廉価版というやつです。

このSC-88ST Proを鳴らしていこうと思います。

音を鳴らす

今回は16音色の構成です。いつか32音構成もやってみたいところですが、MIDIインターフェースを1つしか持っておらず、2系統のものは高価なので暫く先の話になりそうです。

構成

SC-88ST Pro
LEKATO USB MIDI Interface Amazonで2,000円でした
Windowsが動作しているPC WindowsVista以前が用意できると安定します
3.5mmジャックを備えた有線イヤホン

PCとMIDI InterfaceをUSBで接続します。ドライバは自動でインストールされました。

MIDI InterfaceのMIDI OutとSC-88ST ProのMIDI Inを接続します。

最後にSc-88ST Proのフロントの3.5mmイヤホンジャックにイヤホンを挿せば配線は完了です。

必要なソフトウェア

音を鳴らすゲーム・MIDI再生ソフトウェア今回は東方紅魔郷を再生します
CoolSoft MIDIMapper

MIDI Mapperについて

Windows XPまでのWindows OSには規定のMIDIデバイスを設定するMIDI Mapperという機能がありました。

しかしこの機能はWindows Vistaで廃止されています。この問題は東方ProjectのようなMIDIの再生デバイスを指定できないゲームにおいて致命的です。

そこで利用するのがCoolSoft MIDIMapperです。仮想的なMIDIデバイスを作成・リダイレクトすることで任意のMIDIデバイスを規定の出力先に変更できるツールです。

以下の公式サイトからダウンロード・インストールが可能です。

MIDIMapper | CoolSoft

東方紅魔郷

東方紅魔郷は前述した東方Projectの第6作品目の弾幕型シューティングゲームです。Windowsで動作する東方Project作品の中で最古の作品です。

第1作から第5作は旧作と呼ばれ、現代のコンピュータ(PC/AT互換機)ではないPC-98シリーズでのみ動作します。

98シリーズの実機は現在入手困難なため、動作させるにはエミュレータを利用するのが主流ですが今回は割愛します。 (私の技量不足もあり、エミュレータから音を出せませんでした。)

第6作以降はWindowsで動作しますが、MIDIでの出力に対応しているのは第6作～第8作目のみ¹となります。それ以降の作品ではMIDIは非対応です。

また、東方紅魔郷にはWindows 10以降のOSで利用すると暴走するバグがありますが以下のDLLを導入することで回避しています。

crosire/d3d8to9: A D3D8 pseudo-driver which converts API calls and bytecode shaders to equivalent D3D9 ones.

実際の様子

第8作品目である東方永夜抄でも再生してみました。

音を収録する

オーディオインターフェースを利用してSC-88ST Proからの音を収録します。

今回はインターフェースとしてQX1002USBを利用します。

ケーブル配線

MIDI InterfaceとPCの接続に変化はありません。今まではイヤホンに出力していたものをインターフェースに流し込みます。

SC-88ST Proの裏にあるRCA出力からInterfaceに出力し、その音をAudacityで拾います。

このときのインターフェースやミキサの音量調整は、GITYにいる音楽系に詳しい先輩に行ってもらいました。

収録にあたって、安定動作のためにゲームを動作させる(MIDIを出力させる)PCと、Audacityを動作させるPCを分けることにしました。

奥にあるのはGITYでレガシーなソフトウェアを動作させるために私が持ち込んだWindows 7が動作しているノートPCです。

手前のPCにオーディオインターフェースを接続し、デジタル化された音をAudacityで録音しています。

終わり

ハードウェアMIDI音源を聴けるシェアオフィスはGITYだけと言えるように環境を整えたいですね。しかしそんなシェアオフィスの需要はあるのだろうか。

次回は東方Project発足当時のPCであるPC-98シリーズを分解し復活させようと思います。(失敗したらボツにします。)

正確には第9作品「東方花映塚」の体験版まで。旧作については知らないです。 ↩︎

人工の海に執着する群馬県民の昏い情熱

Wed, 19 Mar 2025 18:18:00 +0900

私は富山の出で、実家は漁港近くにある。海なし県に囚われた私を心配しているのか、祖母は私が帰省するたびに地場の魚を振る舞ってくれる。祖母が笑顔で「こちらの魚は美味しいだろう、新鮮さが違うから」と話してくれるたびに、私も魚のおいしさ以上に嬉しくなる。ところで東京-地方漁港スシ議論という概念がある。日本で一番カネとヒトが集まる都市である東京に上等なネタも同じく一極集中するから地方の漁港近辺で食べるスシが新鮮で一番うまいというのは幻想であると主張する東京人と、普通に考えて釣りたてを食べるのが一番うまいだろと主張するその他¹の県民の対立である。これら主張の真偽はさておき²、高速道路開通やコールドチェーンの発達によって群馬県の魚介事情は相当に改善された。もちろん群馬県の超巨大マーケットにアクセスするために物流システムが改善された訳ではなく、東京と日本海側を繋ぐためだ。話は変わるが、古来から抜荷の対策というものは難しいもので、港湾や鉄道ではコンテナの導入まで行方不明になる荷物が相当多かったらしい。なにはともあれ日本海側の漁港で朝に採れた魚は翌日早朝のセリまでに東京に届き、その日のうちに飲食店や小売店に並ぶ。また、漁港近辺のスーパーマーケットでは11時ごろからその日の朝に取れた魚が並び始める。少し話が戻るが、私の祖母は公務員を定年まで勤め上げた厳格な人で、何事も早め早めに済ませてしまう。例えば、私が帰省する2~3日前には魚を買っておいてくれるらしい。

本稿ではGITYで行われているクルマエビの海上養殖の環境監視システムの概要について示す。作成ガイド形式になっているのでエビを養殖したい方はどうぞ。このシステムは文字通り私一人の手によって³一晩で作成されたためアラが多いかもしれない。ダシもよく出る。しかし、昨年9月から現在に至るまで24/365で特にトラブルなく運用できている。

はじめに

まず、GITYのエビ養殖水槽に設置された監視システムはあくまでデモンストレーション用であり、構想/設計のごく一部であることを断っておく。このシステムは無駄にどこかの財閥系企業の鉱山監視システムや無駄に農研機構の通い農業支援システムを参考にして構築され、無駄に農業情報学会のUECSをjsonに改変したものを通信プロトコルとして使用している。これによって無駄に拡張性が高く、なにかの間違いでエビ水槽がGITYフロアを埋め尽くしたり群馬県庁の全フロアがいきなり植物工場と化しても問題なく対応可能である。信頼性が重要なら冗長構成の構築や産業用グレードのボードへの入れ替えも容易に可能である。更に、無駄にWifiやBLE,LoRaといった通信規格にも対応でき、室内の数メートルから屋外の数キロメートル単位でのセンシングも可能である。記録頻度とバーターにはなるが、年単位でセンサ端末の電池を保たせることもできる。完全にオフグリッドでシステム全体を動作させることも、データ基盤をクラウドに設置することも可能だ。 GITYの養殖水槽に置かれているのは最小構成を少しだけ拡張した、有線ベースのコンパクトなバージョンである。次に現物の写真を示す。（設計ミスあり。分かった方は直接対面で私まで！先着で素敵なプレゼント。）

ふざけているのか？

しかし現実のプロトタイピングなんてこんなものである。総務省のICTスタートアップリーグも書類通過した。ここで陰謀論者に朗報――政府は我々を監視していない。

構成概観

ラズパイにマイコンを繋いだだけ。私の名前を横断検索ツールに入れる⁴のは少し話を聞いてからでも遅くは無いと思う。思い出してもらいたいが、日本の誇る産業機械もモーターをたくさん繋いだだけだし、ここ何年間もS&P500の好成績を支えてきたビッグテックの筆頭、Googleの製品も群馬県の高卒（私のことだ）をストーキングして広告をクリックさせるだけのものだ。

このシステムは大きく分けて2つ、大規模化する場合には3つの部分に分かれる。センサを制御するマイコン部分、マイコンから送られるデータを受信し蓄積する小型Linuxマシン、そして小型PCに蓄積されたデータを纏めるクラウドサーバないしメインマシンである。今回のシステムではマイコンを一つと小型Linuxマシンを一つのシンプルな構成になった。更に小さくしたい場合にはGPIOのあるRaspberry Piのようなマシンに直接センサを繋いでやればよい。概要としては以下の図のようになる。

センサー選定

なんでもよい。強いて言うなら、湿度センサを流通過程で湿度管理しているサプライヤは秋月だけしか確認できていないという情報があった。適当に測りたいものが測れるものを買う。今回はBME280、MH-Z19C、DS18B20などを使用する。DS18B20は使用しやすく加工されたものが、なぜか生のセンサと変わらない値段で販売されているため注意。BME系列のセンサは海外通販でお安いものも見つかる。好みで使い分ける。センサー選定の最も重要なポイントは値段や精度よりも使いやすいライブラリがあるかどうかだ。一番のコストは人件費！

マイコン/通信規格

マイコンにもいくつかの種類がある。個人開発で使用しやすいのはArduinoファミリやESP32ファミリだろうか。今回は無駄にArduino mega（の、互換機）を採用した。NANOでよい。またESP32によるwifi経由でのDBへのデータの直接投入や、LoRaモジュールを利用した低消費電力長距離通信などもテストしたが、今回は明らかにオーバースペックなので採用していない。マイコンとセンサをそれぞれいい感じに配線する。長期間運用する場合には面倒でもブレッドボードではなく基盤にはんだ付けしてやること。現代においてはブレッドボードと同じようにランドが繋がっている便利な基盤が市販されている。面倒な配線作業は不要だ。

小型Linuxマシン

実は！小型でもLinuxでもなくてもよい。何事にも全力で当たりたいタイプならフルサイズのデスクトップPCを採用しても特に問題ない。しかし、LoRaモジュールやセンサの接続、運用時間の長さ、供給体制などを考えると産業向けのシングルボードコンピュータが無難な選択だろう。

今回はRaspberry Pi4を採用した。国内ではPi5に給電するための電源が入手しづらいためだ⁵。また、頻繁なMicroSDへの書き込みは寿命を縮めるため、RAMディスクにデータを蓄積して一定間隔で保存する運用か、組み込み向けグレードのSLCのものを使用するのがよいだろう。両方のアプローチを組み合わせてもよい。よくわからなければ「ドライブレコーダー用」と書いてあるMicroSDカードを選べば最低限なんとかなる。またRaspberry piにはH/W watchdog timerが組み込まれているため、これも忘れずに有効にしておくこと。watchdogを追加してくれるhatも市販されているので、そういったものを追加するのもよい。

このマシンでは3つのソフトウェアを動作させる。マイコンと通信してセンサのデータを受け取り、データベースに投入するソフトウェア。これは自作する必要がある。加えて、時系列データベースInfluxDBと可視化ツールGrafanaをインストールする。Dockerで動かしても、直接生環境に入れてしまってもよい。今回は面倒だったので生環境に入れた。それぞれ適切にインストールして適当に連携させる。解説記事はGoogleで検索を行えば無数にヒットし、ChatGPTなりDeepSeekなりに聞けば入力するコマンドまで手取り足取り教えてくれるだろう。かつて先生とすら呼ばれたGoogle検索の威光は消え去り今ではググレカスという単語を聞くことも無くなった。現代社会において驚き屋がエーアイを称賛する鳴き声が朝の時報、検索サービスをググってもカスと揶揄する御宅の鳴き声が夜の時報となっていることからも分かるように実は両者は非常に近い行いでありGoogle検索は2019年にBERTと呼ばれる言語モデルを組み込んでいる検索の劣化は潜在的新規顧客の枯渇による戦略の変化つまり既存ユーザーが更に多く検索しないと有益なサイトにアクセスできなくすればPVが改善するというEnshittificationによる当然の帰結であり技術的な問題ではなく……

言うまでもないがAPIキーのたぐいは各種サービスに入力しないこと。Gitでプロジェクトを管理しているなら、gitignoreの設定も忘れないように。マイコンとの通信にはシリアル通信を使用した。距離次第で規格を変えたり何かしら間に挟んだりするが、今回はデフォルトで問題ない。

すべてがうまくいけば、Grafana上で美しいグラフが見えるはずである。センサーを手で温めたり息を吹きかけてみよう。外部サービスと連携してアラートを飛ばす場合、Grafanaの機能を利用するアプローチとPythonでセンサデータを受け取るタイミングで行うアプローチがある。自分の使用したいサービスが対応しているほうを選ぼう。

クラウド基盤、メインマシン

センサー群をまとめるマイコン、をまとめる小型Linuxマシン、をまとめるために必要。これを導入する場合、先述のラズパイはIoTゲートウェイないしエッジ機器的な立ち位置になる。強力な回線で接続され給電にも不自由しない、例えば工場のような場所で運用するなら単純な機能に特化させてもよいし、モバイル通信すら難しい山奥のような環境で運用するなら適当な処理を行わせてデータ量を減らしてから通信するようにしてもよい。Raspberry piは非常に強力な処理能力を備えており、物体認識タスクを1fps前後でこなす程度ならお茶の子さいさいである。何にせよ大規模になると種々の制約からセンサから送られるデータを一時的にストックする必要がどうしても出てくる。

今回は不要だ。

終わりに

機械に見守られながらエビはすくすくと育ち、肉眼での視認も難しい稚エビから立派な天ぷらサイズにまでなった。彼らの知能は驚くほど高く、なんとGITYにたむろして不定期に奇声をあげる迷惑集団⁶よりも規則正しい生活リズムを有している。人類滅亡の後には覇権を握っていることうけあいである。人類をとりまく自然環境は日々厳しさを増している。私もここ最近バイオマイクロマシン⁷による免疫攻撃に苦しんでいる。たぶん来年くらいに滅ぶだろう。そんな自然環境も鑑みて、次回はいよいよ不安定化する気象状況に左右されず食料を供給する唯一の方法について書いていく。

注釈

栃木県、群馬県、埼玉県、山梨県、長野県、岐阜県、滋賀県、奈良県を除く。 ↩︎
群馬県には太平洋の魚と日本海側の魚が集中するから日本で最もうまいスシが食べられるというのが実際である。 ↩︎
LLMの支援も受けていない。原理的にハードと開発環境のバージョン相性とかサイレントな仕様の破壊的変更とか私の配線ミスとかに対応できないためだ。更に言えば、あれにははんだごてを握れないという重大な欠陥がある。 ↩︎
インターネット上の様々な検索窓にクエリを投入して結果を表示するツール。OSINTで使用されるユーティリティ。 ↩︎
財団のやつらが電源回路をケチったため5V5Aという変な電圧電流を要求する。普通のPD対応機器で給電すると3V5Aでハンドシェイクして一応動きはする。画像認識タスクあたりで全力を出すとシステムが落ちる。 ↩︎
彼らは群馬大学投石学部を名乗りジャンク、工具、専門書、きらら系漫画などを持ち込む、フロアの一部を不当占拠する、怪しいゼミを開催する、寸胴鍋で牛丼を煮るなどの悪行を繰り返している。 ↩︎
花粉。 ↩︎

GITYがHHKBのタッチ&トライスポットになりました

Wed, 12 Feb 2025 00:01:04 +0900

こんにちは。山田ハヤオです。

この度、GITYが株式会社PFUのHHKBのタッチ＆トライスポットとなりました！！

HHKBとは

HHKBは、正式名称Happy Hacking Keyboardという株式会社PFUが販売しているキーボードシリーズの総称です。少ないキー数と合理的なキー配列、世界でも数少ない静電容量無接点方式によるキースイッチによって極上のキーボードとして仕上がっています。

既に高級なキーボードとして確固たる地位を築いており、世界中に多くの愛用者がいます。

HHKBについてより詳しく知りたい方は、公式サイトに掲載されているこちらをご覧ください。

HHKBを触ったことがない人向けのFAQ 10選～筆者がおすすめしたいキーボード！～ | PFU

タッチ&トライスポットとは

タッチ&トライスポットと呼ばれる場所にはHHKBが設置されています。

提携を結んだ日本中のシェアオフィスやコワーキングスペースがタッチ&トライスポットとして登録されており、様々な種類のHHKBを実際に試すことができます。

Happy Hacking Keyboard | タッチ&トライスポット | PFU

上記のページで、日本中のタッチ&トライスポットの写真を見ることができます。

GITYも仲間入りしました‼️

そんなタッチ&トライスポットにGITYも参戦することになりました。

GITYでは以下の機種が設置されており、実際に自分のデバイスと接続して利用することができます。

HHKB Professional HYBRID Type-S 墨日本語配列
HHKB Professional HYBRID Type-S 雪日本語配列
HHKB Professional HYBRID Type-S 墨英語配列
HHKB Professional HYBRID Type-S 雪英語配列
HHKB Studio 墨英語配列
HHKB Studio 雪英語配列

裏話

実はこのタッチ&トライスポットにGITYも参戦できるのでは……？と言い出したのはこの記事の筆者なのでした。

GITYには英語配列を使っているプログラマーが多い¹ので、英語配列のラインナップを多めにしてもらいました。

是非GITYに来て、世界最高峰のキーボードであるHHKBを触ってみてください。

自分の周りの人だけかもしれない…… ↩︎

プロジェクトダッシュボードSeedsnを支える技術

Thu, 16 Jan 2025 22:40:28 +0900

こんにちは、GITYでSeedsnを開発している山田ハヤオです。SeedsnはGITYで進行しているプロジェクトや、これから立ち上げたいプロジェクトを掲示しておき、人と人を繋げていくというプラットフォームです。

当初このアプリは群馬大学の4年生の先輩たちによって開発されており、現在ではそれを私と私の友人が引き継いで開発を続けています。

今回はSeedsnの開発に利用されている技術と、現在の問題点についてお話します。

フロントエンド

採用している主な技術

フロントエンドではReactのフレームワークであるNext.jsを用いています。キャッシュによる最適化やファイルベースなルーティング等、非常に重厚なフレームワークです。 SeedsnではPagesルーティングを採用し、殆どのコンポーネントがCSRで動作しています。

UIライブラリにはMUIを用いています。MUIは旧来はMaterial UIと呼ばれており、React上で動作するUIライブラリとして古くから利用されています。 styled-componentの上に構築されており、Googleの提唱するMaterial DesignをReact上で簡単に実装することができます。

フォーマッタとリンタについて

フォーマッタにはESLint v8系とPrettierを用い、eslint-plugin-prettierでESLint経由でPrettierを実行しています。このプラグインは現在は既に非推奨になっているようですが、フォーマットが行われていない部分が一目瞭然になり便利なため未だに利用しています。

eslint-plugin-prettierとeslint-config-prettierの役割の違いや現在のベストプラクティスは以下に記載されています。

Prettier と ESLint の組み合わせの公式推奨が変わり plugin が不要になった | blog.ojisan.io

注意するべきは、上記のサイトで記載されているベストプラクティスについてはあくまでも「ESLintとPrettierを組み合わせる際の方法」の話に限定されるものであり、実際の設定ファイルの書き方は推奨されるものではありません。

現行のESLint v9以降ではFlat Configと呼ばれる新しい設定ファイルの記述方法がデフォルトとなり、従来のjsonファイルを利用した記述方法は廃止されました。 Flat ConfigはECMA Script Modulesを活用した新たな書き方であり、従来の設定でわかりにくかったextendsやpluginsが利用できなくなりました。

従来までのextendsは記述された文字列を元にESLint側が独自で設定ファイルの依存関係を解決するという形でした。これはESLint側の実装量が多くなる上、コード上では単なる文字列でしかないため関係の記述の複雑さと柔軟性を低下させるものでした。

新しいFlat ConfigではES Modulesによるimport文を用いてパッケージから設定ファイルを直にインポートします。これが意味するところは、旧来まではESLintによって独自に行っていた依存関係の解決とインポートをJavaScriptエンジンに委任するということです。

設定の記述が大きく変わり破壊的変更も多く加えられた結果、Next.jsがFlat Configをサポートするようになったのは最新のNext.js 14になってからでした。 SeedsnではNext.js 13を利用しているため、これらの最新の設定方式を記述することができません。

リンタのためだけにアプリケーションフレームワークのメジャーバージョンを更新するべきかというと、私は決してその必要はないのではないかと思います。開発メンバーの多くはNext.js 14で導入された新機能をふんだんに活用するほど精通していませんし、現在のSeedsnに導入するにはそれなりの規模の改修が必要になります。

現在はBiomeやXOといった選択肢も登場しており、今後の動向次第ではこちらに乗り換えることになるかもしれません。

状態管理

Seedsnはその性質上、アプリケーションが多くの状態を保持する必要があります。

初期の頃のSeedsnではContextを用いていたものの、これらの更新による不必要な再レンダリングやコード量の増加等を考慮した結果 Jotaiを導入することになりました。 JotaiはRecoilの意思を継いだ状態管理ライブラリであり、ReduxやZustandとは異なりatomという小さな状態を複数個保持しています。

SeedsnではJotaiを採用していますが、状態管理ライブラリに大きく依存することを避けるためにAtomをexportせずにカスタムフック内で隠蔽しています。隠蔽は以下のように行います。例えば、なにかの金額をグローバルに管理するという場合には以下のようになります。

1
2
3
4


import { useAtom, atom } from "jotai"
const moneyAtom = atom<number | null>(null)

export const useMoney = ():number | null => useAtom(moneyAtom)

各コンポーネントはuseMoneyを使い、Jotaiの存在を認知することはありません。

将来的に状態管理ライブラリに大きな変革が起きた場合やJotaiが利用できなくなった場合等にも容易に対処できるよう、できる限りライブラリへの依存は薄めていく方針です。

データ取得

データ取得も同様にJotaiを用いています。Jotaiを採用した大きな理由の一つにAsync atomの存在があります。

使い方はReact 19におけるuseフックに近く、フック内でデータ取得を行います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


import { atom, useAtom } from "jotai"
import { APIClient } from "@/utils"

const projectsAtom = atom(async (get) => {
 const api = new APIClient()
 const res = await api.getProjects()
 if (!res.ok) {
 return null
 }
 return await res.json()
})

export const useProjects = () => useAtomValue(projectsAtom)

実際にはもう少し要件が複雑になるため同様のコードというわけではないのですが……

やはり先程も言った通り、ライブラリへの依存を抑えて書き換えやすくするということに焦点を当てています。フロントエンドの業界は流行の変化が激しいので、それに追従できる形のコーディングを心がけています。

また、APIClientも注目してほしい部分です。後述するバックエンドサーバーと通信を行うために記述したクライアントラッパーであり、シンプルな実装ながら非常に実用的です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


interface TypedResponse<T> extends Response {
 json(): Promise<T>;
}

type PromiseRes<T> = Promise<TypedResponse<T>>;

export class BaseClient {
 /**
 * @param baseUrl APIのベースURL
 */
 private readonly baseUrl: string;

 constructor(baseUrl: string) {
 this.baseUrl = baseUrl;
 }

 fetch = <T>(endpoint: string, method: string, cookie?: string, body?: unknown): PromiseRes<T> =>
 fetch(`${this.baseUrl}/api/${endpoint}`, {
 headers: new Headers({
 "Content-Type": "application/json",
 Cookie: cookie ?? ""
 }),
 method,
 body: JSON.stringify(body),
 credentials: "include"
 });

 get<T>(endpoint: string, cookie?: string): PromiseRes<T> {
 return this.fetch(endpoint, "GET", cookie);
 }
}

export class APIClient {
 private readonly backend: BaseClient;

 private readonly cookie: string = "";

 /**
 * @param cookie ユーザーのCookie
 */
 constructor(cookie = "") {
 this.backend = new BaseClient("https://example.com");
 this.cookie = cookie;
 }

 getProjects = (): PromiseRes<{ projects: Project[] }> => this.backend.get("projects", this.cookie);
}

fetchAPIを型定義と共にラップしたBaseClientと、実際のエンドポイントが記述されたAPIClientで構成されています。これにより各コンポーネントでAPIのURLを直に記述することなくサーバーのエンドポイントを叩くことができます。

この実装の現在の課題は型定義です。fetchのデコード結果のany型を強引に書き換える形で型定義を実現しているのですが、実際にサーバーから受け取った値をチェックしているわけではないので型安全とは言えません。

Tanstack QueryのqueryFnとしてAPIClientを指定し、Zodでバリデーションを行うというのが理想でしょう。運の良いことにJotaiとTanstack Queryを統合するライブラリが公式によって紹介されています。

Query — Jotai, primitive and flexible state management for React

今後、データフェッチでの型安全性が重要視される場合には導入することになるかもしれません。 Jotaiは比較的薄いライブラリであるため、こういった複数のライブラリ同士での組み合わせが行いやすいのも特徴です。

今後の展望

フロントエンド業界は今後ますますRSCの世界が中心になっていくでしょう。そうなった際にstyled-componentは足枷になる可能性があります。

パフォーマンスにどの程度重点を置いて開発するかというのは規模感や技術力に依存するのでしょうが、果たしてSeedsnの規模はRSCを念頭に置く必要があるのかどうか。残念ながら実践経験の少ない私にはそれらを見極める方法がありません。GITYにいるエンジニアさんにはよく「そこまで気にしなくてもいいんじゃない?」と言われますが、効率やパフォーマンスを強く意識してしまうが故に開発速度やプライオリティを軽視しがちなのは私の課題なのではないかと思います。

バックエンド

利用している技術やサービス

バックエンドにはGolangとバックエンドフレームワークであるGinを用いています。

データベースにはSupabaseを用いており、supabase-goというコミュニティによって開発されたライブラリを用いて通信を行っています。このライブラリはORMのような重厚なものを利用しておらず、PostgRESTというPostgreSQLのREST APi Wrapperを用いています。

認証バックエンドにはKeycloakやGoogleを用い、OpenID Connectと呼ばれるOAuth 2を利用したプロトコルを用いて認証・認可を行っています。 go-oidcはOpenID ConnectをGolangで実装するためのライブラリであり、Fedora CoreOSのチームが開発してます。 Golang準公式のoauth2を拡張する形で利用することができます。

データベースとの通信について

supabase-goではSQL文のような感覚でメソッドチェーンを記述しSupabaseからデータを取得できます。准公式という扱いらしく、コミュニティ主導によって開発されているライブラリのようです。その実装はpostgrest-goを薄くラップしたもので、クエリで実際に記述しているもののほとんどの実装はこちらのライブラリに書かれています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


func GetProjects() ([]Project, error) {
 var projects []Project
 var resp interface{}
 _, err := client.From(projectListTable).Select("*", "", false).ExecuteTo(&resp)
 if err != nil {
 return projects, err
 }

 // convert to JSON byte array
 jsonData, err := json.Marshal(resp)
 if err != nil {
 return err
 }

 // unmarshal
 err = json.Unmarshal(jsonData, &projects)
 if err != nil {
 return err
 }

 return projects, nil
}

上記のプロジェクト一覧を取得する際のコードの一部分です。 jsonライブラリで構造体にマッピングしてあげるだけなので、取得されたデータの扱いはhttpリクエストの結果を処理するのと全く同様になります。

軽量でSQLに近い書き方ができるので学習コストが低い一方で、ORMやスキーマ定義を行っていないので構造変更が起きた際のマイグレーションに非常に苦労します。こちらも規模の小さいアプリケーションには非常に向いていますが、今後規模が拡大していくとなった際に課題になりそうな部分です。

またこちらもフロントエンドと同じくGolangの型定義以上のバリデーションを行っていないため、安全なコードであると言い切ることはできません。これらは早急に何かしらのバリデーションライブラリを用いてチェックを実装したいところです。

終わり

Seedsnは群馬大学の情報学部の学生が勉強しながら開発をしているアプリケーションです。 Next.js等のモダンなフレームワークを採用し、高速かつ少ないランニングコストで実行できます。

一方で、比較的新しい技術を積極的に用いているとはいえ最新とは言い難い状況です。更に、バリデーションや型チェック等の細かな部分の粗が目立ってしまっているのも現実です。

開発当初はページ全体のレンダリングが停止してしまうようなバグが頻発し不安定だった時期もありました。今後はモダンな技術を採用しつつも安定性や安全性に重点を置いたアップデートを行っていきたいです。

またSeedsnで大きな採用技術の変更や、開発で大きな壁に遭遇した際にはブログに書こうと思います。最後まで読んでいただきありがとうございました。

GITYブログはじめました

Mon, 06 Jan 2025 18:03:25 +0900

こんにちは、GITYで活動している学生の山田ハヤオです。

GITYには様々な活動をしている学生が多くおり、もちろん情報学部の学生もたくさんいます。

こういった学生がもっと気軽に専門的な内容を発信できるよう、(午前6時にふと思いついて)このブログを立ち上げました。

目的

大変ありがたいことに、GITYには非常に多くの学生と専門的な知識を持った大人が集まって日々活動しています。その中にはCATENASに直接関わっている方々もいれば、そうでない人々もいるでしょう。

せっかくそういった専門性があるコミュニティが形成されているのですから、それをアウトプットしないのは非常に勿体ないことだなと感じました。アウトプットを行うことでコミュニティ全体の活性化が行われるとともに、GITYという場所がどういったことをしているのかを発信することで外部の人に知ってもらえたら良いなと思っています。

記事を書きたい

記事の書き方をご覧ください。

Posts on GITY Blog

地域創⽣・社会課題解決 AI プログラミング コンテストに参加してきました！

コンテストについて

初めに

知見の広がりと学び

日本各地の取り組み

参加してみての学び

発表を通じて見えた外に出す価値

AWSコンテストを通して気づいた「伝える力」

最初のプレゼンで感じたこと

フィードバックに支えられて

5回を通じての気づき

おわりに

来たるべきAI地方幕府時代に向けて畑を耕す

これはなに

はじめに

準備

畝の作成/マルチング/植え付け

終わりに

告知

駄菓子屋ひびのば&次世代の塾Sociusで働く私のおしごと

初めまして

簡単に自己紹介

なんの仕事してるの？

Sociusのミッション

駄菓子屋ひびのばってなに？

SNSも頑張ってます

仕事の中で大事にしていること

自己決定の機会をなるべく多く作る

終わりに

お前のバックエンドサーバーは20行でMCP Serverになる

事前知識のおさらい

MCPとは? LLMのTypeCと呼ばれる謎の物

MCP Serverとは

ckanthony/gin-mcpはすごいぞ

GITYで開発されている実際のプロジェクトに導入してみた

元になるコード

追加するコード

Clineから呼び出してみた

ClineにMCP Serverを登録する

実際に呼び出してみる

終わり

東方Projectの音楽をSC-88ST Proで聴ける環境を構築した話

MIDIとは

SC-88STPro

音を鳴らす

構成

必要なソフトウェア

MIDI Mapperについて

東方紅魔郷

実際の様子

音を収録する

ケーブル配線

終わり

人工の海に執着する群馬県民の昏い情熱

はじめに

構成概観

センサー選定

マイコン/通信規格

小型Linuxマシン

クラウド基盤、メインマシン

終わりに

注釈

GITYがHHKBのタッチ&トライスポットになりました

HHKBとは

タッチ&トライスポットとは

GITYも仲間入りしました‼️

裏話

プロジェクトダッシュボードSeedsnを支える技術

フロントエンド

採用している主な技術

フォーマッタとリンタについて

状態管理

データ取得

今後の展望

バックエンド

利用している技術やサービス

データベースとの通信について

終わり

GITYブログはじめました

地域創⽣・社会課題解決 AI プログラミングコンテストに参加してきました！