Claude Haiku 5.5は、Anthropicが2026年10月7日にリリースしたClaude 5.5シリーズの小型モデルです。

高速な応答性能と低コストを両立しており、要約や分類、コーディング支援などの日常的なタスクに適したモデルとして提供されています。Haiku 5.5はAnthropic史上最も高速かつ低コストな小型モデルとして位置付けられています。

Claude Haiku 5.5の特徴

1. 高速な応答速度

Haiku 5.5は応答速度を重視したモデルです。

そのため、

• チャット形式での質問
• 要約
• ドキュメント作成
• コーディング支援

などの軽量なタスクを短時間で処理できます。

2. 優れたコストパフォーマンス

Claude Haiku 5.5の大きな特徴の一つがコストパフォーマンスの高さです。

Anthropicの発表によると、Claude Haiku 5.5の料金は入力100万トークンあたり0.35ドル、出力100万トークンあたり1.75ドルとなっており、前世代のHaiku 4.5と比較して約75％のコスト削減が実現されています。

また、上位モデルであるSonnet 5.5と比較すると、入力コスト・出力コストともに大幅に低く設定されているため、日常的な利用や大量のリクエストを伴う開発業務に適しています。

3. Sonnet 5.5との比較

Claude 5.5ファミリーには上位モデルとしてSonnet 5.5があります。

比較すると、

Haiku 5.5が向いている用途

• 要約
• ドキュメント作成
• 軽量なコーディング
• コードレビュー
• 日常的な質問

Sonnet 5.5が向いている用途

• 大規模リファクタリング
• 複雑な設計
• エージェント開発
• 高度な推論を伴うタスク

ベンチマーク上ではSonnet 5.5の方が高性能ですが、コストは高くなります。簡単な作業であればHaiku 5.5で十分対応できるケースが多く、コスト効率に優れています。 

まとめ

Claude Haiku 5.5は、高速性・低コスト・十分な性能を兼ね備えたモデルです。

特に、

• 簡単なコーディング
• ドキュメント作成
• 要約
• 情報整理

といった日常業務では十分な性能を発揮します。

AI利用コストを抑えながら開発効率を向上させたい場合に、有力な選択肢の一つといえるでしょう。

The post コスパ最強モデル！Claude Haiku 5.5について first appeared on FreeStyleVision.

i-ReporterのGatewayには、クラスター値を更新する前に確認メッセージを表示する機能と、処理完了後に完了メッセージを表示する機能が用意されています。
今回の製造対応では、これまで利用したことがなかった完了メッセージ表示機能を初めて活用することになったため、実装にあたり確認メッセージ表示機能とあわせて動作や設定方法を調査しました。

Gateway連携の確認・完了メッセージとは？

これまでGatewayを実行した際にメッセージを表示できるのはエラー発生時のみでしたが、2026年2月18日にリリースされた「Gateway 2.7.260200」からは、処理が正常に完了した場合にもメッセージを表示できるようになりました。
また、誤操作によるクラスター値の意図しない更新を防ぐため、反映前に確認メッセージを表示する機能も追加されました。

検証環境

・i-Repo Gateway：2.8.260700
　※2.7.260200以上が必要
・i-Reporter for Windows：6.2.26020
　※・6.2.26020以上が必要
　　・iOS版アプリの場合は「8.2.26020」以上が必要

事前準備

【i-Reporter帳票】
Gatewayの実行ボタンのみを設定した帳票定義を用意します。

【Gateway実行プログラム】
帳票定義で「Gateway実行ボタン」をクリックした際に実行される、jsonとPythonのプログラムを用意します。
≪確認メッセージ設定情報≫
　・メッセージタイトル：確認メッセージ
　・メッセージ内容：確認メッセージを実行してもよろしいでしょうか？
≪完了メッセージ設定情報≫
　・メッセージタイトル：完了メッセージ
　・メッセージ内容：Gatewayの実行を完了しました
　・背景色コード：251,154,12
　・タイトル文字色コード：26,150,226
　・メッセージ文字色コード：205,83,179
　・表示時間：3秒

確認メッセージ表示検証

【検証手順】
①帳票上の「Gateway実行ボタン」をクリックする

②Gatewayで通信を行う画面が一瞬表示される

③Gatewayの通信画面から確認メッセージに切り替わる

【検証結果】
Gatewayの実行ボタンをクリックすると即座に確認メッセージが表示されるため、サイクルタイムが短い運用でも十分活用できると感じました。
また、確認メッセージが表示されている間は、i-Reporterアプリ本体のボタンを含む他の操作は行えず、「はい」「いいえ」の選択のみが可能となります。そのため、利用者に確実な確認を促し、意図しない操作を防止する仕組みとして有効です。
一方で、確認メッセージのタイトルやメッセージ内容の変更は可能でしたが、フォントサイズやダイアログの大きさ、ボタンの表示内容などのレイアウトに関する設定は行えないため、利用する際は標準的なメッセージ画面の範囲内で運用を検討する必要があります。

完了メッセージ表示検証

【検証手順（確認メッセージ表示検証の続き）】
①帳票上の確認メッセージの「はい」をクリックする
　※「いいえ」をクリックすると、元の画面に戻ります

②帳票上部に完了メッセージが表示される

③完了メッセージ設定情報の表示時間で設定した時間（今回の検証では3秒）の経過後、
　メッセージは徐々に薄くなり、自動で消える
　※iOS版アプリでは設定した時間が経過すると一瞬で消えます

【検証結果】
完了メッセージは確認メッセージと異なり、背景色やタイトル文字色、メッセージ文字色を自由に設定できます。そのため、GatewayでDB更新を実行する場合のように、処理結果が帳票上に直接反映されず利用者から見えにくいケースでも、処理完了を通知する手段として活用できると感じました。
また、表示時間を「0」に設定した場合は、「×」ボタンをクリックするまでメッセージが表示され続けるため、通知を確実に認識してもらいたい場合にも有効です。
一方で、メッセージの表示位置やサイズは変更できず、常に帳票上部へ横長の形式で表示されるという制約があるため、利用する場合は表示位置を考慮しての帳票レイアウトを検討する必要があります。

まとめ

確認メッセージの表示中は「はい」「いいえ」以外の操作ができなくなるため、利用者の誤操作の防止に有効であり、完了メッセージは帳票上では結果が見えにくいGateway処理の実行完了を通知する手段に有効であることがわかりました。
ただし、どちらのメッセージ機能も表示位置やサイズなどに制約があるため、活用する場合にはメッセージ表示を考慮した帳票レイアウトを検討する必要があるとともに、今後のバージョンアップで追加設定できるようになることを期待します。

The post 【i-Reporter】i-Repo Gateway連携の完了メッセージ first appeared on FreeStyleVision.

SQLを書いていて「このクエリ、なんか遅いな」と感じたとき、一番最初に疑うべきはインデックスだと思っています。今日はそのインデックスについて、実際にローカルでDBを立てて手を動かしながら、どこに貼るのがベストプラクティスなのかを検証していこうと思います。

結論から言うと、インデックスは「WHERE・JOIN・ORDER BYで使われる列」に貼るのが基本で、それ以外の場所にむやみに貼ると逆に遅くなることすらあります。この感覚を、実際の実行計画を見ながら確認していきます。

1. まずはローカルにDB環境を作る

今回はDockerでPostgreSQLを1本立てて検証します。手元にDockerさえあれば数分で用意できます。

docker run --name pg-index-demo -e POSTGRES_PASSWORD=postgres -p 5432:5432 -d postgres:16

起動したら、psqlで接続します。

docker exec -it pg-index-demo psql -U postgres

検証用に、注文データを想定したテーブルを作ります。実際のサービスでありがちな「usersテーブル」と「ordersテーブル」の2つです。

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email TEXT NOT NULL,
    status TEXT NOT NULL
);

CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INT NOT NULL,
    status TEXT NOT NULL,
    created_at TIMESTAMP NOT NULL
);

データが少ないとインデックスの効果が見えないので、100万件のダミーデータを流し込みます。

INSERT INTO users (email, status)
SELECT 'user' || i || '@example.com', 'active'
FROM generate_series(1, 100000) AS i;

INSERT INTO orders (user_id, status, created_at)
SELECT
    (random() * 99999 + 1)::int,
    (ARRAY['pending','paid','shipped','cancelled'])[floor(random()*4+1)],
    NOW() - (random() * 365 || ' days')::interval
FROM generate_series(1, 1000000) AS i;

2. インデックスなしで検索してみる

まずは何も手を加えず、特定ユーザーの注文を検索してみます。

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 12345;

手元で実際に実行してみると、こういう実行計画が返ってきました。

Gather  (cost=1000.00..12841.43 rows=11 width=23) (actual time=12.597..29.450 rows=8 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  ->  Parallel Seq Scan on orders  (cost=0.00..11840.33 rows=5 width=23) (actual time=6.466..19.566 rows=3 loops=3)
        Filter: (user_id = 12345)
        Rows Removed by Filter: 333331
Planning Time: 0.216 ms
Execution Time: 29.508 ms

「Parallel Seq Scan」というのは、テーブルを2つのワーカーで手分けしながら頭から全部舐めて条件に合う行を探しているということです。100万行のうち欲しいのはたった8行なのに、並列化してもなお29.5msかかっています。これがインデックスがない状態の実態です(ちなみに手元の環境ではワーカーが2つ自動的に割り当てられましたが、CPUコア数や設定によっては単純な「Seq Scan」1本になることもあります)。

3. インデックスを貼ってみる

ではuser_id列にインデックスを貼ってみます。

CREATE INDEX idx_orders_user_id ON orders (user_id);

もう一度同じクエリを実行してみます。

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 12345;

Bitmap Heap Scan on orders  (cost=4.51..47.30 rows=11 width=23) (actual time=0.028..0.038 rows=8 loops=1)
  Recheck Cond: (user_id = 12345)
  Heap Blocks: exact=8
  ->  Bitmap Index Scan on idx_orders_user_id  (cost=0.00..4.51 rows=11 width=0) (actual time=0.024..0.024 rows=8 loops=1)
        Index Cond: (user_id = 12345)
Planning Time: 0.207 ms
Execution Time: 0.066 ms

実行時間が29.5msから0.066ms、400倍以上速くなりました。「Bitmap Heap Scan」は、まずインデックス側で該当する行の場所だけをビットマップとして特定し(Bitmap Index Scan)、そのあとで実際に必要なブロックだけをテーブル本体から読みにいく、という2段構えの読み方です。取得件数がある程度あるときにPostgreSQLがよく選ぶ実行計画で、件数がごく少なければ単純な「Index Scan」になることもあります。いずれにしても、テーブル全体を読むのではなくインデックスという「目次」を使って必要な行にピンポイントでアクセスできるようになったからこそ、この差が出ています。数字で見ると、インデックスの効果がここまではっきり出るのかと、実際に試すたびに驚きます。

4. どこにインデックスを貼るのがベストプラクティスか

ここまでで効果は分かったので、次は「どこに貼るべきか」を整理していきます。

WHERE句・JOIN句で絞り込みに使う列

今回のuser_idのように、検索条件やJOINの結合キーになる列は最優先で候補にすべきです。特に外部キーとして使う列には、迷わずインデックスを貼っています。

ORDER BYやGROUP BYで使う列

並び替えや集計に使う列にもインデックスは効きます。試しにcreated_at列で並び替えてみます。

EXPLAIN ANALYZE
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20;

インデックスがない状態では、こうなりました。

Limit  (cost=30503.05..30505.38 rows=20 width=24) (actual time=64.656..67.883 rows=20 loops=1)
  ->  Gather Merge  (cost=30503.05..127732.14 rows=833334 width=24) (actual time=64.637..67.861 rows=20 loops=1)
        Workers Planned: 2
        Workers Launched: 2
        ->  Sort  (cost=29503.03..30544.69 rows=416667 width=24) (actual time=60.649..60.651 rows=17 loops=3)
              Sort Key: created_at DESC
              Sort Method: top-N heapsort  Memory: 27kB
              ->  Parallel Seq Scan on orders  (cost=0.00..18415.67 rows=416667 width=24) (actual time=4.635..32.824 rows=333333 loops=3)
Planning Time: 0.311 ms
Execution Time: 68.084 ms

全行を並列でスキャンしてから上位20件だけをソートで抜き出しているため、68msかかっています。ここでcreated_atにインデックスを貼ってみます。

CREATE INDEX idx_orders_created_at ON orders (created_at DESC);

Limit  (cost=0.42..2.08 rows=20 width=24) (actual time=0.024..0.084 rows=20 loops=1)
  ->  Index Scan using idx_orders_created_at on orders  (cost=0.42..82966.79 rows=1000000 width=24) (actual time=0.023..0.080 rows=20 loops=1)
Planning Time: 0.390 ms
Execution Time: 0.105 ms

68msから0.105msに短縮されました。インデックスがソート済みの順序をあらかじめ持っているため、その順番をそのまま辿るだけで上位20件が取れるようになったからです。

カーディナリティ(値の種類の多さ)を意識する

ここは見落としがちなポイントです。試しに、値の種類が4つしかないstatus列にインデックスを貼ってみます。

CREATE INDEX idx_orders_status ON orders (status);

EXPLAIN ANALYZE
SELECT * FROM orders WHERE status = 'paid';

Bitmap Heap Scan on orders  (cost=2835.89..12641.23 rows=253867 width=23) (actual time=4.482..25.556 rows=249556 loops=1)
  Recheck Cond: (status = 'paid'::text)
  Heap Blocks: exact=6632
  ->  Bitmap Index Scan on idx_orders_status  (cost=0.00..2772.43 rows=253867 width=0) (actual time=3.872..3.873 rows=249556 loops=1)
        Index Cond: (status = 'paid'::text)
Planning Time: 0.225 ms
Execution Time: 30.955 ms

インデックスは一応使われていて(Bitmap Heap Scan)、インデックスを外して同じクエリを実行すると62msかかったので、効果はゼロではありません。ただしuser_idのときの400倍のような劇的な差ではなく、せいぜい2倍程度です。全体の4分の1(約25万行)がpaidに該当するため、1行ずつインデックス経由で拾うメリットがそこまで大きくならないからです。

では、もっとカーディナリティが低い場合はどうなるか。試しに、trueとfalseがほぼ50%ずつのis_paid列(BOOLEAN)にインデックスを貼ってみます。

ALTER TABLE orders ADD COLUMN is_paid BOOLEAN;
UPDATE orders SET is_paid = (random() < 0.5);

CREATE INDEX idx_orders_is_paid ON orders (is_paid);

EXPLAIN ANALYZE
SELECT * FROM orders WHERE is_paid = true;

Seq Scan on orders  (cost=0.00..24249.00 rows=500967 width=24) (actual time=76.010..176.902 rows=499646 loops=1)
  Filter: is_paid
  Rows Removed by Filter: 500354
Planning Time: 0.334 ms
Execution Time: 196.384 ms

インデックスを貼ったにもかかわらず、完全に無視されてSeq Scanになりました。値がほぼ2択で、しかもどちらの値でも全体の半分がヒットしてしまうため、インデックス経由で1行ずつ拾うより、テーブルを順番に読んだほうがオプティマイザにとって速いと判断されるからです。実際、あとでpg_stat_user_indexesを確認しても、このidx_orders_is_paidはidx_scanが0のまま、つまり一度も使われていませんでした。カーディナリティが低い列に単独でインデックスを貼っても、使われないどころか書き込みコストだけが増えるケースがあるということを、ここで実感しました。

複合インデックスは列の順番が命

「特定ユーザーのpaid注文」のように複数条件で絞り込むことが多いなら、複合インデックスが効きます。

CREATE INDEX idx_orders_user_status ON orders (user_id, status);

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 12345 AND status = 'paid';

Index Scan using idx_orders_user_status on orders  (cost=0.42..16.48 rows=3 width=24) (actual time=0.185..0.187 rows=1 loops=1)
  Index Cond: ((user_id = 12345) AND (status = 'paid'::text))
Planning Time: 0.638 ms
Execution Time: 0.319 ms

0.3msで終わっています。ここで大事なのは列の順番です。カーディナリティが高い(値の種類が多い)user_idを先頭に置くのが基本で、逆にすると絞り込みの効きが悪くなります。等号(=)で絞る列を先頭、範囲検索(>や<、BETWEEN)で絞る列を後ろに置く、というのが自分の中でのルールになっています。

5. 貼りすぎ注意 ─ インデックスのデメリット

ここまで「貼れば速くなる」という話をしてきましたが、インデックスはタダではありません。INSERT・UPDATE・DELETEのたびに、テーブル本体だけでなくすべてのインデックスも更新する必要があるため、書き込みが多いテーブルにインデックスを増やしすぎると、今度は書き込み性能が落ちます。

また、ディスク容量もインデックスの分だけ余分に消費します。「使われていないインデックス」は保守コストしか生んでいないので、定期的にpg_stat_user_indexesなどで実際の使用状況を確認し、使われていないものは削除する、というのを運用の中に組み込んでおくのがいいと思っています。

SELECT relname, indexrelname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0;

実際に手元の環境でこれを流すと、先ほどのis_paid列のインデックスがしっかり引っかかってきました。

 relname |    indexrelname    | idx_scan
---------+--------------------+----------
 orders  | idx_orders_is_paid |        0
(1 row)

まとめ

今回ローカルで検証してみて改めて感じたのは、インデックスは「なんとなく全部の列に貼っておく」ものではなく、実際のクエリパターンとカーディナリティを見て、狙って貼るものだということです。

迷ったときの自分なりのチェックリストはこうです。WHEREやJOINで絞り込みに使う列か。ORDER BYやGROUP BYで使う列か。カーディナリティは十分に高いか。複合インデックスなら等号条件の列が先頭になっているか。そして、貼った後は実際にEXPLAIN ANALYZEで効いているかを必ず確認する。

「なんとなく遅い」で終わらせず、実行計画を見て判断する癖をつけることが、インデックス設計では一番大事なポイントなんじゃないかなと思っています。

The post どのカラムにインデックスを貼るべきか？SQLチューニングのベストプラクティス first appeared on FreeStyleVision.

AIを使って開発をするようになってから、「一番時間をかけるべき工程はどこか」という感覚が、昔とはまったく変わりました。今日はその話をしてみようと思います。

結論から言うと、私が今一番時間をかけているのは「設計書」です。次に「テスト」、そして「AIのルール決め」、最後に「コーディング」という順番になっています。昔の自分からすると、正直信じられない順番です。

1. 設計書 ─ 一番時間をかけるべき工程

以前の私は、設計書には特にこだわりがありませんでした。概要レベルのものがあれば十分で、実装するときも仕様を軽く確認する程度。ほとんど設計書を見返すこともありませんでした。

ですが、今のAI開発ではそうはいきません。AIがどのように実装する想定なのか、というところまで踏み込んで、実装レベルの設計書に落とし込んでいく必要があります。ここでAIと自分の認識をしっかり合わせておくことが、何よりも大切だと感じています。

ここまでやると何が起きるかというと、出来上がった設計書を渡してプロンプトを一発投げるだけで、ほぼ100%開発が完成するんです。設計書を念入りに練り上げることが、そのまま実装までのパイプラインになっている感覚です。

従来は「設計」と「製造」を分けて考えるのが当たり前でしたが、今は設計書を作るという一つの工程が、そのまま製造まで完了させてしまう。工程そのものの構造が変わってしまったなと感じています。

2. テスト

次に重要なのがテストです。ユニットテストなどでコードの品質自体は担保できても、「本当に仕様どおりに作られているか」の確認はやはり別問題です。ここは避けて通れません。

AIを使ってテスト自体を自動化することも可能ですが、それでも最終的に「本当にできているのか」を確かめるには、人間の目で見るしかないと思っています。ここはまだ人間が担うべき領域だと感じている部分です。

3. AIのルール決め

3番目はAIのルール決めです。これは、AIがこのプロジェクトの中でどう振る舞うべきかを事前に定義しておく作業です。

必ず守るべきアーキテクチャのルール、DBへのアクセスのルール、命名規則など、成果物の品質を担保するために欠かせない工程だと思っています。

こういったルールを事前に決めておかないと、想定していないところまでAIが勝手に変更してしまうことがあります。ルール決めをサボると、あとで思わぬところで痛い目を見るので、ここは絶対に省略できないと感じています。

4. コーディング

そして最後がコーディングです。設計書さえきちんとできていれば、実装はすべてAIに任せています。

正直なところ、自分が最後に手でコードを書いたのがいつだったか、もう思い出せないくらいです。

まとめ

昔は「設計はざっくり、実装で頑張る」というスタイルでしたが、AI開発の今は完全に逆転しました。設計書 → テスト → AIのルール決め → コーディングという順番で時間をかけるようになり、実装そのものにかける時間はどんどん減っています。

「どこに時間をかけるか」という感覚そのものをアップデートすることが、AI時代の開発では意外と大事なポイントなんじゃないかなと思っています。

The post AI開発時代、一番時間をかけるべきはどこか first appeared on FreeStyleVision.

普段からClaude Codeを使っている方なら、「あのコマンド何だっけ?」となった経験、一度はあるんじゃないでしょうか。私自身、最初のうちはコマンドを覚えきれず、毎回ヘルプを見返していました。

この記事では、私が実際によく使っているClaude Codeのコマンドをまとめてみました。全部覚える必要はなくて、まずはこの記事にあるものだけ押さえておけば、日々の作業はかなりスムーズになると思います。

よく使うコマンド一覧

/resume ─ 前回のセッションを再開する

作業を中断して、あとで続きから再開したいときに使うコマンドです。実行すると過去のセッション一覧が表示されるので、そこから選んで再開できます。「昨日の続きをやりたいけど、どこまで進めたか忘れた…」というときにとても便利です。

/usage ─ 使用状況を確認する

今どれくらい使っているのか、セッション数や日々の利用状況などをまとめて確認できるコマンドです。使いすぎていないか気になったときに、こまめにチェックする習慣をつけておくと安心です。

/model ─ モデルを切り替える

タスクの内容に応じてモデルを切り替えたいときに使います。
がっつり複雑な設計を考えたいときは高性能なモデルに、単純な作業をサクサクこなしたいときは軽量なモデルに、といった使い分けができます。

/goal ─ 目標を設定してブレを防ぐ

長めのセッションになると、途中で本来のゴールから話がそれてしまうことがあります。そんなときに/goalで「今回はこれを達成する」という目標を明確にしておくと、Claudeが一貫してその方向に沿って作業を進めてくれるようになります。
また途中でトークンの使用量にリミットが来ても、/goalをしておけばリミットが解除されたときに自動で続きを始めてくれます。

ultrathink ─ じっくり考えてほしいときのキーワード

ultrathink は、そのターン（1回の応答）限定でClaudeに最大の拡張思考（Extended Thinking）を行わせるための指示キーワードです。
設計方針で悩んでいるときや、なかなか解決しないバグに当たったときなど、「じっくり考えてから答えてほしい」場面で”ultrathink”という言葉をプロンプトに入れると、Claudeがより深く思考してから応答してくれます。ちょっとしたタスクにまで毎回使うと逆に時間がかかってしまうので、ここぞという場面で使うのがおすすめです。

まとめ

今回紹介したのは、resume・usage・model・goal・ultrathinkの5つです。どれも派手な機能ではありませんが、日々の作業の中でじわじわと効いてくるものばかりだと感じています。

まずはこの中から気になったものをひとつ試してみて、自分の作業スタイルに合いそうであれば、少しずつ使うコマンドを増やしていくのがおすすめです。

The post Claude Code よく使うコマンド first appeared on FreeStyleVision.

Maestroは、モバイルアプリおよびWebアプリ向けのUI自動テストフレームワークです。YAML形式のシンプルなシナリオを記述することで、実際のユーザー操作を再現しながらアプリの動作を自動で検証できます。

Flutterアプリのテストにおいては、アプリ内部のコードを直接操作するのではなく、実機やエミュレーター上で動作しているアプリに対してタップや入力などの操作を行います。そのため、ユーザーが実際に使用する環境に近い形でテストを実施できます。

また、MaestroはAndroidとiOSの両方に対応しており、近年ではFlutterアプリのE2Eテストツールとして広く利用されています。

2. Maestroの特徴

① シンプルなテスト記述

MaestroではYAML形式を採用しているため、複雑なプログラムを書くことなくテストシナリオを作成できます。可読性も高く、テスト内容を理解しやすいことが特徴です。

以下は、ログイン画面のテスト例です。

[java]
appId: com.example.app
 
—
– launchApp
– tapOn: &quot;メールアドレス&quot;
– inputText: &quot;test@example.com&quot;
– tapOn: &quot;パスワード&quot;
– inputText: &quot;password&quot;
– tapOn: &quot;ログイン&quot;
– assertVisible: &quot;ホーム&quot;
[/java]

この例では、アプリの起動後にメールアドレスとパスワードを入力し、ログインボタンを押下しています。最後に「ホーム」という文字が表示されることを確認することで、ログイン処理が正常に完了したかを検証しています。

② 実ユーザーに近いテスト

端末上の画面要素を直接操作するため、ユーザーの実際の操作を再現したテストを実施できます。画面遷移や入力操作など、実運用に近い検証が可能です。

③ Flutterとの高い親和性

MaestroはFlutterのSemantics Treeを利用してUI要素を認識します。そのため、Flutterアプリを特別なテスト環境へ変更することなく利用できます。

④ システム画面のテストが可能

アプリ内部だけではなく、通知や権限許可ダイアログなど、OSレベルの画面も含めたテストを実施できます。

3. Flutterで利用するメリット

FlutterにはWidget TestやIntegration Testといったテスト手法がありますが、Maestroを利用することで、より実際の利用環境に近い形で動作確認を実施できます。

また、Flutterアプリへの特別なライブラリ追加や複雑な設定が不要であり、既存プロジェクトにも導入しやすい点がメリットです。

さらに、Flutterの内部実装ではなく表示されたUIを対象としてテストを実施するため、アプリの改修やFlutterバージョンの更新による影響を受けにくく、保守性の高いテスト環境を構築できます。

4. 手作業での確認を自動化

アプリ開発では、機能追加や不具合修正のたびに同じ動作確認を繰り返し実施する必要があります。

例えば、

• アプリを起動する
• ログインする
• データを登録する
• 登録内容を確認する
• ログアウトする

といった操作は、開発のたびに何度も実施されます。

Maestroを利用することで、これらの確認手順を自動化できます。一度テストシナリオを作成すれば、同じテストを何度でも繰り返し実行できるため、確認作業の効率化につながります。

また、人による操作ミスや確認漏れを防止できるため、品質の安定化にも効果があります。さらに、開発者は単純な確認作業ではなく、機能開発や改善業務により多くの時間を割くことができます。

5. まとめ

Maestroは、モバイルアプリ向けのUI自動テストフレームワークであり、Flutterアプリに対して実際のユーザー操作に近い形でテストを実施できるツールです。

主な特徴として、

• YAMLによるシンプルなテスト記述
• 実ユーザーに近いUIテスト
• Flutterとの高い親和性
• システム画面を含めたテストへの対応

が挙げられます。

また、これまで手作業で実施していた動作確認を自動化できるため、テスト工数の削減と品質向上の両立が可能です。Flutterアプリ開発における効率的な品質管理を実現するツールとして、Maestroは非常に有効な選択肢であると考えられます。

The post FlutterのMaestroとは first appeared on FreeStyleVision.

システム保守作業の一環として、稼働中のサーバーに対してWindowsUpdateを実施しました。
今回はWindowsの設定画面から更新プログラムの適用を行いましたが、その中で配信された「KB890830」 の適用に想定以上の時間を要したため、備忘録として記載します。

更新プログラム「KB890830」とは？

今回のWindowsUpdateで配信された「KB890830」について、詳細を簡単に記載します。
「KB890830」は「悪意のあるソフトウェアの削除ツール（Malicious Software Removal Tool）」の更新プログラムであり、毎月配信されることが多いですが一般的なセキュリティ更新プログラムとは少し役割が異なります。
このツールはWindowsUpdateの一部としてバックグラウンドで実行され、主な目的は「流行している特定のマルウェアやウイルスを検出・削除」することにあります。実行時には感染している可能性のあるマルウェアの検査を行い、対象となるマルウェアが検出された場合は削除処理を実施します。また、マルウェアによって変更された一部のシステム設定を元の状態に戻す機能も備えています。
ただし、一般的なウイルス対策ソフトとは異なり、常時監視やリアルタイム監視の機能は無く、新たなマルウェア感染を防止するものでもありません。

実行環境

・サーバー：WindowsServer2019 Standard
・Cドライブ
　・ドライブ容量：59.4G
　・使用率：68%
・Dドライブ
　・ドライブ容量：339G
　・使用率：30%
・ストレージ：SSD

悪意のあるソフトウェアの削除ツールの実行

今回の環境では、WindowsUpdateの更新プログラム一覧に「KB890830」が表示されていたものの自動的には実行されなかったため、MicrosoftUpdateカタログから更新プログラムを取得し、「悪意のあるソフトウェアの削除ツール x64 – v5.142（KB890830）」を手動で実行しました。

【KB890830のexeファイルの実行手順】
①「次へ」を押下

②「フルスキャン」を選択し、「次へ」を押下

③スキャンが完了するまで待機

④スキャンが完了したことを確認

⑤スキャン結果の詳細を確認
　※スキャン結果が全て「感染していません」となっていることを確認

【実行結果】
今回実施した「悪意のあるソフトウェアの削除ツール（KB890830）」によるスキャンでは、マルウェアの検出はなく、問題がないことを確認できました。
一方で、スキャン処理の完了までに約7時間要したため、想定以上に長時間となるケースもあるため注意が必要です。

まとめ

「悪意のあるソフトウェアの削除ツール（KB890830）」は定期的に配信されるセキュリティ対策ツールですが、実行中は他の保守作業や動作確認のスケジュールに影響を与える可能性があります。そのため実行する際は後続作業や実行する時間帯を考慮したうえで計画的に実施することが重要です。
また、ツールには進捗バーが表示されますが、進捗バーが右端まで到達した時点で必ずしもスキャンが完了するわけではなく（進捗バーは処理全体の正確な完了率を示しているものではない）、表示だけを判断材料とせず、余裕を持ったスケジュールを組むことの重要性も今回の検証を通じて確認できました。

The post 【WindowsUpdate】悪意のあるソフトウェアの削除ツール(KB890830) first appeared on FreeStyleVision.

前回は、AWS Kiroに搭載されている Agent Focus の概要や特徴について紹介しました。Agent Focusは、従来のコード中心の開発スタイルではなく、AIエージェントとの対話を中心に開発を進めるための機能です。

今回はその続編として、実際にAgent Focusを使用し、AIエージェントによる開発支援を体験しました。実際の操作画面や生成された成果物を確認しながら、使用方法や利便性、活用の可能性について検証した結果を紹介します。

Agent FocusでTODOリストを作成

エージェントへ作業を依頼

Agent Focusの機能を確認するため、新しいセッションを作成し、エージェントに簡単なTODOリストアプリの作成を依頼しました。

今回入力した指示内容は以下のとおりです。

Kiroは指示を受けると、まず依頼内容を分析し、実装に必要なタスクを整理します。
その後、作成したタスクごとに順番に処理を実行していきます。

コード生成結果の確認

実装が完了すると、エージェントは作成した内容の説明と実行方法を提示してくれました。

また、以下の画像のように画面右側には追加・変更されたファイルが表示されます。
変更されたファイルを選択するとIDEが開き、実際のコードや変更内容を確認することができます。

生成されたファイルを実行し、動作を確認しました。
その結果、シンプルなTODOリストアプリが作成されており、タスクの追加および削除機能が正常に動作することを確認できました。

追加機能の実装

基本機能の動作確認後、さらにAgent Focusの活用方法を確認するため、追加機能の実装を依頼しました。

今回は、タスクの進捗状況を視覚的に確認できるようにするため、円グラフによる表示機能の追加を依頼しました。
今回入力した指示内容は以下のとおりです。

実装が開始されると、エージェントは既存のコードを解析し、円グラフを表示するために必要な機能についてもあわせて検討を行いました。その結果、円グラフの表示機能だけでなく、タスクの完了状態を管理するための「完了／未完了」切り替え機能も自動的に実装されました。

生成されたファイルを実行し、動作を確認しました。その結果、完了済みタスクと未完了タスクの割合が円グラフとして表示されるだけでなく、タスクの完了状態を切り替える機能も追加されていることを確認できました。

当初は円グラフの追加のみを依頼していましたが、エージェントが機能の目的を理解し、必要と判断した関連機能まで実装していた点が非常に印象的でした。単純に指示された内容を実装するだけでなく、アプリとして成立するために必要な機能を補完しながら開発を進めていることが分かりました。

まとめ

今回、AWS KiroのAgent Focusを使用し、TODOリストアプリの作成および機能追加を行いました。

実際に利用した結果、自然言語で指示を与えるだけでエージェントがタスクを整理し、実装から修正、機能追加までを進める様子を確認できました。また、作業状況やコード差分をリアルタイムで確認できるため、開発者は実装作業そのものよりも成果物の確認や品質管理に集中できると感じました。

特に今回の検証では、コードを一切記述することなくアプリケーションの作成から機能追加まで実現することができました。 従来の開発では、設計からコーディング、デバッグまでを開発者が担当していましたが、Agent　Focusでは開発者が要件を伝え、AIエージェントが実装を担当するという新しい開発スタイルを体験することができました。

もちろん現時点では、生成されたコードの確認や品質担保は開発者自身が行う必要があります。しかし、AI技術の進化によって、今後は開発者がコードを書く機会そのものが減少し、要件定義や設計、レビューといった上流工程に注力する時代が訪れる可能性もあると感じました。

今回の検証を通じて、Agent Focusは単なるコード生成ツールではなく、AIと協力して開発を進める新しい開発環境であることを実感しました。今後の発展にも大いに期待したいと思います。

The post AWS KiroのAgent Focusを使ってみた first appeared on FreeStyleVision.

Agent Focusは、AWSが提供するAI開発環境「Kiro」に搭載された機能であり、AIエージェントとの対話を中心に開発を進めるための新しいユーザーインターフェースです。従来のIDEではコードエディタが画面の中心に配置されていましたが、Agent Focusではチャット画面が中心となり、開発者はAIエージェントに指示を出しながら開発を進めることができます。

Agent Focusは、「Chat-first（チャット中心）」の開発スタイルを実現することを目的としています。開発者はコードを直接記述するだけでなく、AIエージェントに開発作業を任せながら進捗を管理し、必要に応じて修正指示を行うことができます。

Agent Focusの画面は、以下の3つのエリアで構成されています。

• Agents Panel（左側）
  • エージェントセッションの管理
  • 複数タスクの監視
  • 実行状況の確認
• Chat Panel（中央）
  • AIエージェントとの対話
  • タスク依頼
  • 指示やフィードバックの実施
• Auxiliary Panel（右側）
  • 仕様書（Spec）の確認
  • 変更ファイルの確認
  • コード差分の表示

2. Agent Focusの使い方

① Agent Focusへ切り替える

Kiro IDEの右上にある「Agent Focus」ボタンをクリックすると、通常のIDE画面からAgent Focus画面へ切り替えることができます。また、必要に応じて通常のIDE画面へ戻ることも可能です。

② 新しいセッションを作成する

Agent Focusでは、新規セッションを作成し、AIエージェントへ作業を依頼します。

選択可能なワークフローの例は以下のとおりです。

• Spec
• Plan
• Bug Fix
• Quick Spec

③ エージェントへ指示を出す

例えば、以下のような指示を入力します。

• ログイン機能を実装してください
• ユーザー管理画面を作成してください
• このバグの原因を調査してください

指示を入力すると、エージェントが要件分析や実装作業を開始します。

④ 作業内容を確認する

エージェントが変更したファイルやコード差分は、右側のAuxiliary Panelに表示されます。

開発者は内容をレビューし、問題がなければ承認します。また、必要に応じて追加の指示を出し、修正を依頼することもできます。

3. Agent Focusの活用方法

① 機能開発

新機能の追加をエージェントへ依頼できます。

例

• 商品管理機能
• 会員登録機能
• 認証機能

などの実装を依頼し、設計からコーディングまで支援を受けることができます。

② バグ修正

不具合情報を伝えることで、

• 原因調査
• 修正案作成
• テスト実施

までをエージェントが支援します。

例えば、

・ログイン画面でクラッシュする問題を修正してください

と指示すると、関連コードを調査し、修正内容を提案してくれます。

③ 複数タスクの並列実行

Agent Focusでは、複数のセッションを同時に管理できます。

例として、以下のような運用が可能です。

開発者は複数の作業状況を一覧で確認できるため、生産性の向上が期待できます。

④ 仕様書との連携

Agent Focusは、KiroのSpec機能と連携しています。

要件から以下の内容を生成し、仕様に沿った開発を進めることができます。

• Requirements（要件）
• Design（設計）
• Tasks（タスク）

これにより、開発途中での要件漏れや設計上の不整合を防ぐことができます。

⑤ チーム開発

Agent Focusは、Steering機能と組み合わせることで効果を発揮します。

Steeringに

• 使用言語
• フレームワーク
• コーディング規約

などを登録しておくと、エージェントはそれらのルールに従って開発を進めることができます。

4. まとめ

Agent Focusは、AWS Kiroに搭載されたチャット中心の開発インターフェースであり、AIエージェントとの対話を通じて開発を進めるための機能です。従来のコード中心の開発スタイルとは異なり、開発者はエージェントへ指示を出し、進捗を管理する役割を担います。

主な特徴として、以下が挙げられます。

• AIエージェントとの対話型開発
• 複数タスクの並列管理
• Specとの連携による仕様駆動開発
• Steeringとの連携による開発ルールの統一

今後、AIエージェントがソフトウェア開発において重要な役割を担うことが予想される中で、Agent Focusは「人間がコードを書く」開発スタイルから、「AIエージェントを管理しながら開発する」新しい開発スタイルを実現する重要な機能であると考えられます。

The post AWS KiroのAgent Focusとは first appeared on FreeStyleVision.

i-ReporterのGatewayは、一般的には帳票へ何かしらのデータを自動入力するために利用されることが多い機能です。
しかし今回、帳票への自動入力を目的とするのではなく、i-Reporterで入力したデータを外部システムへ連携するためのデータ送信機能としてGatewayを活用したので、本記事では外部システムへのデータ送信をする場合の注意点について記載します。

Gateway連携とは？

ここで改めてi-Repo Gateway（旧称：ConMas Gateway）で何をすることができるかを簡単にまとめます。

≪概要≫
i-Repo Gatewayは外部データの情報をリアルタイムに取得するもので、i-Reporterの標準機能として利用できます。

≪主な機能・用途≫
①外部データファイル連携
　外部のシステムから出力したファイル（CSVやExcelなど）のデータ情報を取得し、i-Reporterの帳票へ
　自動入力します。

② データベース連携
　外部システムまたは、i-Reporterのデータベースからデータを取得し、i-Reporterの帳票へ自動入力します。

③ 外部システムへのデータ出力
　i-Reporterの帳票に入力した値を、外部システムにデータ送信やデータベースに登録・更新します。

※本記事は③の内容になります。

データ送信機能の活用紹介

今回活用したのは、i-Reporterの帳票に入力した値をデータベースへ登録・更新する用途ではなく、帳票の入力値を外部機器へ送信するためのデータ連携機能として利用しました。

データ送信検証①

メーカーのマニュアルでは、i-Reporter帳票へ値を反映することを前提としたPythonコードのサンプルが掲載されています。そのため、サンプルコードを参考に実装する場合は、処理結果をi-Reporter帳票のクラスターへ反映する仕組みとなります。
ですが、今回は外部機器へのデータ送信を目的としており、i-Reporter帳票へ値を反映する必要は無いため、サンプルコードとは異なりJSON形式でレスポンスを返却しない実装を試しました。

【検証手順】
①i-Reporterアプリでデータ送信するクラスターに値を入力し、Gatewayの実行ボタンをクリックする

②画面が「通信中」の状態のままとなり、処理が終了しないという問題が発生

【検証結果】
外部機器へのデータ送信自体は正常に行われましたが、i-Reporterアプリ側では処理完了の応答を受け取れず、画面が「通信中」の状態のままとなり、処理が終了しないという問題が発生しました。
この結果から、帳票へ値を反映しない場合であっても、Gatewayを実行する場合は必ずJSON形式でレスポンスを返却する必要があります。

データ送信検証②

「データ送信検証①」の結果から、i-Reporter帳票へ値を反映しない場合であっても、Gatewayを実行する場合にはJSON形式でレスポンスを返却する必要があることが分かりました。
そのため、i-Reporter帳票へ値を反映せずJSON形式でレスポンスを返却する方法として、帳票のクラスター（Index0）へフォーカスを当てる内容をJSON形式で返却する方法を試しました。

【検証手順】
①i-Reporterアプリでデータ送信するクラスターに値を入力し、Gatewayの実行ボタンをクリックする

②設定したクラスター（Index0）へフォーカスが自動で当たる

【検証結果】
i-Reporter帳票のクラスターへフォーカスを当てる内容をJSON形式で返却する方法であれば、外部機器へのデータ送信とGateway処理の完了を問題なく実現できることを確認できました。
そのため、最終的にこの方法での開発を採用しました。

まとめ

JSON形式のレスポンスを返却しない場合、外部機器へのデータ送信自体は成功していても、i-Reporterアプリ側では処理が完了したと認識されず、「通信中」の状態が継続してしまうことがわかりました。
そのため、Gatewayを利用して外部機器へデータ送信を行う場合でも、GatewayからのレスポンスとしてJSON形式のデータを必ず返却する必要があります。
また、今回のように帳票へ値を反映する必要がない場合は、特定のクラスターへフォーカスを当てる内容をJSON形式で返却することで、正常に処理を完了させることができます。

The post 【i-Reporter】帳票に値を返さない場合のi-Repo Gateway連携 first appeared on FreeStyleVision.