FURYU Tech Blog - フリュー株式会社

フリュー株式会社の開発者が技術情報を発信するブログです。

TSKaigi 2026 参加レポート

はじめに

こんにちは
ピクトリンク開発部でサイト開発に携わっている横山です🐱
今回は2026/05/22-23に開催されたTSKaigi 2026に参加しましたので,その内容について書かせていただきます.

2026.tskaigi.org


セッション

AI Agent に“攻略本”を渡したら、150フォームの移行が回り始めた話

speakerdeck.com

弊社でもAI活用は著しく普及しており,業務でよく発生する作業のいくつかはskillとなっています.

descriptionにトリガーワードを並べておくと/skillで指定しなくとも自然なプロンプトからskillを適用してくれるようになる

ふむふむ・・🥱

さっそく自分で作成したskillや利用しているskillをみてみると,ちゃんと設定されていました.

このセッションを見るまでskillにdescriptionが設定されていることすら知らなかったのです😺

skillを作成するためのskillが用意されており,その中にdescriptionの自動最適化設定も組み込まれていたようで,知らず知らずのうちに設定できていたみたい・・・

skill作成者に感謝🌷

実際に,skillを指定しなくとも〇〇やって〜とプロンプトを投げると該当するskillが自動で適用されました!かしこい!

 

ファイル名や関数名を機械的に命名することでレビュー観点が激減する

これについてはぜひ!ほんとうに!やりたいなと思うのですが,莫大な修正が生まれることとなりそうなので今後のリファクタ案件としてやっていきたいです😴

 

勝負はコードを書く前につく

ここ最近はもっぱらAIを利用して実装の計画書を出力している身からすると,これは核心すぎました.

実装時ではなく,プランニングの時点で最終的な成果の良し悪しが決まっています!ほんとうに!

すでにほとんどの方がそんなことわかってますよという感じだと思いますが,プランニングを適当にやりすごした暁には,実装時に何倍もの工数となってそのツケが襲いかかってきます😵‍💫

ですので,何事もAIを利用するときはプランニングの徹底をしていきたいです.

 


AI活用の格差をなくす:チーム全体のAI開発生産性を底上げする方法

speakerdeck.com

勝負はコードを書く前につく

先ほどのセッションからの学びとして上記について言及しましたが,このセッションでも同様のことが語られていました.

開発フェーズにおいてplan・cordingフェーズは個人でのAI活用となるため,AIスキルによりコードの品質に差が生じる

  • slopなコードが大量に紛れ込む
  • 0.1%の間違ったコードを探す負荷

バイブコーディングにより人間のレビュー負担が大きくなったというのは誰しもが感じていることだと思います.

プランニング時点で細かくレビューすることにより,その負担が少しでも軽減できるといいなと個人的に思っています😿

 

計画書についてもgit上で管理することでレビューを受けられるようにする

同感で,わたしが所属しているチームでもAIを利用して出力した計画書をgit管理するようにしています.

そして,計画書の出力まではペアでタスクに入るようにしていて,ダブルチェックしています.

細かな指示を汲んだ計画書から出力されるコードは粗い指示のものより精度もよく,手直しが少ないと感じています.

 


「バイトル」のTypeScriptリニューアル — 積み上がったレガシーとパフォーマンスに挑む現在地

speakerdeck.com

ピクトリンクのサイトも長年生き延びてきたレガシーサイトなので,発表に共感する部分が多くありました.

つい最近もフレームワークのバージョンアップにとっても工数がかかってしまったりなど・・🤧

ピクトリンクのサイトのフロント部分は主にTypeScriptで書かれているため,発表内にあったTypeScriptのパフォーマンス改善が気になりました.

ということで,

ピクトリンクのサイトのある1画面の改善をちょっとだけやってみました!

 

light houseスコア改善
- 現状 -

light houseスコアを計測してみると,

Performance 58
Accessibility 83
Best Practices 58
SEO 100✨

という結果となりました.

SEO以外は改善の余地ありという感じですね🤧

light houseのスコアは90以上が良好とのことなので,手っ取り早く良好に行けそうなAccessibilityの改善を実施してみたいと思います.

 

- 改善 -

light houseの詳細を見てみるとスコアが落ちている原因箇所を教えてくれているので,そこをピンポイントで直していけばよさそう・・・✏️

  • 1つめ:Links do not have a discernible name

これはリンクに識別可能な一意のリンクテキストをつけてくれというものらしい!

とのことなので,

aria-label

を該当のリンクに付与しました.

 

  • 2つめ:Heading elements are not in a sequentially-descending order

見出しであるHeading要素が降順になっていないよとのことなので,

<h1>hoge</h1> <h3>fuwa</h3>

となっていたのを

<h1>hoge</h1> <h2>fuwa</h2>

に修正しました.

 

  • 3つめ:Document does not have a main landmark

<main>を設定してねとのことなので,適切な部分をdivタグからmainタグに修正しました.

 

最終的なlight houseスコアを計測してみると

Accessibilityが83→90に💖

良好な数値まで改善することができました.

本当はPerformanceやBest Practicesの改善もちょっっっと🤏🏻だけやってみたのですが,うまくスコアを改善できず・・・また次の機会にリベンジさせてください😿

 


まとめ

TS Kaigiに参加して得られた知識から,現在のピクトリンクのサイトがどうなっているかをいろいろみてみました.

まだまだ改善の余地あり!とのことで,引き続きリファクタリングを実施していきたいと思います🦾✨

また次の記事でお会いできますように!記事出せますように!😽